[Pgsql-ayuda] Problema con funciones

[Antonio Castro]

On Fri, 20 Jun 2003, Alvaro Herrera wrote:

> > En Postgres por desgracia la codificaci=F3n afecta a text, char(n),=20
> > varchar(n), y no se cuantas cosas m=E1s. No hab=EDa necesidad de afecta=
r
> > al tipo char(n). Yo creo que al usar codificacion multibyte tanto
> > para char(n), como para varchar(n) estamos desperdiciando la posibilida=
d
> > 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=F3n multibyte. Si yo quiero usar un campo para codificar
> > art=EDculos con cuatro caracteres los acentos y la e=F1es me sobran.=20
>=20
> Lo que sucede es que el estandar dice que char(n) debe limitar el string
> a n _caracteres_, no n bytes. =20

Efectivamente el estandar creo que dice exactamente eso.

Parece que han interpretado al pie de la letra el estandar pero con eso=20
en mi opini=F3n 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=F3n en la
forma de codificar caracteres asi que codificar varchar(n) de
una forma y char(n) de otra tal como sugiero, tampoco supondr=EDa=20
una violaci=F3n del estandar. Creo m=E1s bien lo contrario.

El estandar se hizo as=ED para proporcionar un tipo distinto a varchar=20
que permitiera un almacenamiento mas eficiente y con un n=FAmero de=20
caracteres fijo, pero un n=FAmero de caracteres fijo solo representa=20
una aut=E9ntica ventaja cuando se implementa con un n=FAmero de bytes fijo.=
=20

Cuando se dise=F1o el estandar no se pens=F3 en la posibilidad de la=20
codificac=EDon multibyte. Por eso cuando se introduce la codificaci=F3n=20
multibyte en lugar de respetar al pie de la letra el estandar habr=EDa sido=
=20
mejor en mi opini=F3n respetar el esp=EDritu del estandar, (ocupaci=F3n en
bytes fija) porque eso es en lo que pensaban los que dise=F1aron el=20
estandar aunque lo expresaran de otra forma. char(n) fue dise=F1ado para
implementar esos campos peque=F1os que suelen usarse para incluir c=F3digos=
=20
o referencias.=20

Dejarle sin codificaci=F3n multibyte no me parece grave porque no solo=20
se usan poco los acentos sino que rara vez interesan las min=FAsculas.=20

En ese tipo de campos se puede usar cosas como 'CORUNYA', 'ANYO', etc.
sin problemas. Si se necesita usar 'CORU=D1A' y 'A=D1O' y no te importa=20
perder algo de rendimiento siempre te quedar=EDa el recurso de poner ese=20
campo con varchar(n). Pienso que habr=EDa sido bueno implementado as=ED des=
de=20
un principio y no habr=EDa pasado nada. Si se sacara ahora una versi=F3n
donde char(n) siempre usar=E1 codificaci=F3n monobyte existir=EDa un proble=
ma=20
de incompatibilidad con datos de versiones anteriores que obligar=EDa a
pasar algunos campos char(n) a varchar(n) para no perder informaci=F3n.

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

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

> De todas maneras, hace algun tiempo Manfred Koizar public=F3 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:
>=20
> http://archives.postgresql.org/pgsql-performance/2002-10/msg00089.php

No lo conoc=EDa y parece ser un parche bastante bueno:

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

    : You easily can add your own type, say char99, by editing the Makefile=
=2E
    : Simply add char99.o to OBJS, and char99.sql to the fixchar.sql line.
=09
Adem=E1s es tan sencillito que tiene valor did=E1ctico para los que est=E9n
pensando en implementar un nuevo tipo de datos. Muy interesante.

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

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


--=20
Un saludo
Antonio Castro

       /\     /\   Ciberdroide Inform=E1tica=20
         \\W//  << http://www.ciberdroide.com >>
        _|0 0|_                                                   =20
+-oOOO-(___o___)-OOOo---------------------+=20
| . . . . U U . Antonio Castro Snurmacher | =20
| . . . . . . . acastro@ciberdroide.com   |=20
+()()()---------()()()--------------------+