Re: [Pgsql-ayuda] Problema con funciones

On Fri, 20 Jun 2003, Alvaro Herrera wrote:

> > En Postgres por desgracia la codificación afecta a text, char(n),
> > varchar(n), y no se cuantas cosas más. No había necesidad de afectar
> > al tipo char(n). Yo creo que al usar codificacion multibyte tanto
> > para char(n), como para varchar(n) estamos desperdiciando la posibilidad
> > de respetar el tipo char(n) para campos de longitud fija. Yo creo que
> > el uso de char(n) y varchar(n) se convierte en la misma cosa cuando se
> > usa codificación multibyte. Si yo quiero usar un campo para codificar
> > artículos con cuatro caracteres los acentos y la eñes me sobran.
>
> Lo que sucede es que el estandar dice que char(n) debe limitar el string
> a n _caracteres_, no n bytes.

Efectivamente el estandar creo que dice exactamente eso.

Parece que han interpretado al pie de la letra el estandar pero con eso
en mi opinión no basta. Luego me explico.

> Si un caracter usa mas de un byte, como
> vas a representar esa informacion? El campo es de longitud fija para el
> humano, pero la maquina puede necesitar longitud variable.

Yo no creo que el estandar mencione ninguna restricción en la
forma de codificar caracteres asi que codificar varchar(n) de
una forma y char(n) de otra tal como sugiero, tampoco supondría
una violación del estandar. Creo más bien lo contrario.

El estandar se hizo así para proporcionar un tipo distinto a varchar
que permitiera un almacenamiento mas eficiente y con un número de
caracteres fijo, pero un número de caracteres fijo solo representa
una auténtica ventaja cuando se implementa con un número de bytes fijo.

Cuando se diseño el estandar no se pensó en la posibilidad de la
codificacíon multibyte. Por eso cuando se introduce la codificación
multibyte en lugar de respetar al pie de la letra el estandar habría sido
mejor en mi opinión respetar el espíritu del estandar, (ocupación en
bytes fija) porque eso es en lo que pensaban los que diseñaron el
estandar aunque lo expresaran de otra forma. char(n) fue diseñado para
implementar esos campos pequeños que suelen usarse para incluir códigos
o referencias.

Dejarle sin codificación multibyte no me parece grave porque no solo
se usan poco los acentos sino que rara vez interesan las minúsculas.

En ese tipo de campos se puede usar cosas como 'CORUNYA', 'ANYO', etc.
sin problemas. Si se necesita usar 'CORUÑA' y 'AÑO' y no te importa
perder algo de rendimiento siempre te quedaría el recurso de poner ese
campo con varchar(n). Pienso que habría sido bueno implementado así desde
un principio y no habría pasado nada. Si se sacara ahora una versión
donde char(n) siempre usará codificación monobyte existiría un problema
de incompatibilidad con datos de versiones anteriores que obligaría a
pasar algunos campos char(n) a varchar(n) para no perder información.

Sería bueno que se empezara recomendando el uso correcto de
char(n) y varchar(n) y en una futura versión hacer el cambio que yo
sugiero.

Yo cuando diseño una tabla y tengo un campo de tipo caracter de menos de
diez caracteres pongo char(n) y en caso de 10 o más pongo varchar(n) o
text.

> De todas maneras, hace algun tiempo Manfred Koizar publicó en
> pgsql-general un tipo especifico para columnas de largo fijo, con
> bastante ganancia de rendimiento. Puede servirte si lo necesitas para
> algo. El mensaje de anuncio esta aqui:
>
> http://archives.postgresql.org/pgsql-performance/2002-10/msg00089.php

No lo conocía y parece ser un parche bastante bueno:

: User data types char3, char4 and char10 as space saving
: replacements for char(3), char(4), and char(10) respectively.

: You easily can add your own type, say char99, by editing the Makefile.
: Simply add char99.o to OBJS, and char99.sql to the fixchar.sql line.

Además es tan sencillito que tiene valor didáctico para los que estén
pensando en implementar un nuevo tipo de datos. Muy interesante.

Parece que implementa estos nuevos tipos por concatenacion de "char".

Lo que no entiendo es que se tenga que recurrir a este parche cuando la
idea del estandar para char(n) en mi opinión era precisamente esta.

--
Un saludo
Antonio Castro

/\ /\ Ciberdroide Informática
\\W// << http://www.ciberdroide.com >>
_|0 0|_
+-oOOO-(___o___)-OOOo---------------------+
| . . . . U U . Antonio Castro Snurmacher |
| . . . . . . . acastro(at)ciberdroide(dot)com |
+()()()---------()()()--------------------+