[Pgsql-ayuda] Problema con funciones

[Antonio Castro]

On Fri, 20 Jun 2003, Alvaro Herrera Munoz wrote:

> On Fri, Jun 20, 2003 at 08:05:11AM +0200, Antonio Castro wrote:
> > On 19 Jun 2003, Manuel Sugawara wrote:
> >=20
> > > usas iso-8859-5. Esto es lo bonito de unicode (utf-8 por ejemplo), qu=
e
> > > la ? y los caracteres cir?licos, ?rabes, chinos etc pueden convivir
> > > todos juntos, sin embargo algunos caracteres te van a tomar dos o tre=
s
> > > bytes mientras que en las codificaciones iso-8859-X todos los
> > > caracteres toman un solo byte.
> >=20
> > Me da la impresi?n que esto afecta al rendimiento de los indices
> > sobre campos de tipo char(n).
>=20
> Pura especulacion, o hiciste mediciones?

Si es pura especulaci=F3n. Para hacer una pruebecita r=E1pida y mal prefier=
o
no hacerla. De todas formas seg=FAn los casos la diferencia de tama=F1o de
los campos indexados puede ser superior al doble. Sospecho que almenos
en alg=FAn caso si pueda representar un menor rendimiento. Es solo sentido=
=20
com=FAn pero no puedo afirmarlo categoricamente.

> > Con el unicode creo que estos campos
> > pasan a tener un almacenamiento con un n?mero variable de bytes.
> > Sin unicode un char(4) ocupa cuatro bytes nada m?s. No digo que sea
> > un problema grave, pero si lo veo como una desventaja.
>=20
> Unicode no es la unica codificacion multibyte.

Bueno las otras codificaciones multibyte tendr=E1n el mismo problema.

> Si quieres usar una codificacion mono-byte pero poder usar "legalmente"
> valores no ASCII (acentos, etc), usa una codificacion iso-8859-1 o
> iso-8859-15.  Usar SQL_ASCII es buscarse problemas en general.

Y si quiero usar codificacion mono-byte para un campo y usar=20
Unicode en otros campos me tendr=E9 que fastidiar claro.

> En todo caso, para Postgres los campos char(n), varchar(n) siempre tienen
> un numero variable de bytes.  De hecho un char(4) usa un minimo de ocho
> bytes (los cuatro primeros indican el largo en bytes de lo que viene).
> Incluso char(1) usa minimo 5 bytes.
>=20
> Por eso recomiendo usar "char" con las comillas para almacenar un solo
> caracter.  Eso te limita a no usar cosas multibyte y no lleva los 4
> bytes de largo al principio.

Pues precisamente el uso de "char" con comillas pone de manifiesto
una cosa. Un sistema de codificaci=F3n no tiene porque afectar=20
necesariamente a todos los tipos que se basan en el uso de caracteres.

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 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=F3n multibyte. Si yo quiero usar un campo para codificar
art=EDculos con cuatro caracteres los acentos y la e=F1es me sobran.=20

Si se hubiera dejado al marjen el tipo char(n) se podr=EDa elegir entre
char(n) y varchar(n) para cosas distintas. Es decir si alguien quiere=20
usar acentos y e=F1es podr=EDa recurrir a varchar(n) y si no quiere
usar acentos y le conviene codificar de manera eficiente unos indices de
tama=F1o fijo con cuatro caracteres podr=EDa usar el tipo char(4).=20

Quiz=E1s exista algo tipo "char (n)" entre comillas o similar y yo no
lo conozco. "char" est=E1 muy bien pero para campos de un solo byte.
Puede que exista soluci=F3n al problema que planteo pero primero no
la conozco y segundo me parece un desperdicio que char(n) y varchar(n)
se comporten exactamente igual usando codificaci=F3n multibyte.


--=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
+()()()---------()()()--------------------+