From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Antonio Castro <acastro(at)ciberdroide(dot)com> |
Cc: | Manuel Sugawara <masm(at)fciencias(dot)unam(dot)mx>, Fernando Papa <fpapa(at)claxson(dot)com>, Pgsql-ayuda(at)tlali(dot)iztacala(dot)unam(dot)mx |
Subject: | Re: [Pgsql-ayuda] Problema con funciones |
Date: | 2003-06-21 16:49:51 |
Message-ID: | 20030621164951.GA12026@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
On Sat, Jun 21, 2003 at 09:36:37AM +0200, Antonio Castro wrote:
> 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).
> >
> > 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.
Bueno, esa es tu interpretación del estándar. Pero recuerda que tu caso
particular es muy simple -- digamos que para toda Europa occidental y
América el caso es muy simple, pues nuestros alfabetos caben casi
completamente en 8 bits (o podemos limitarlo fácilmente si lo
necesitamos). Pero si te vas a otra parte del mundo esto ya no es así.
Te recuerdo que dos de los miembros "senior" del equipo de desarrollo
son japoneses (Tatsuo Ishii y Hiroshi Inoue) y son precisamente los que
se han preocupado del tema multibyte.
> 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.
Hmm... esto es discutible por la misma razón.
En realidad me parece que los desarrolladores no están interesados en
implementar su propia interpretación del estándar, viendo "que era lo
que estaban pensando en realidad los tipos que lo escribieron". Más
bien la idea es implementar al pie de la letra lo que dice. Piensa que
si no haces esto, el estándar en la práctica es inútil porque cada
proveedor va a implementar su propia idea...
> 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.
Y eso como lo sabes?
> char(n) fue diseñado para implementar esos campos pequeños que suelen
> usarse para incluir códigos o referencias.
Y por qué no usas un identificador numérico mejor? El rendimiento es
aún mejor, es más fácil de manejar, etc. Supongo que aquí entramos en
un tema de gustos.
> 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.
Discutible.
> > 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.
>
> No lo conocía y parece ser un parche bastante bueno:
Ojo con las implicancias... si realmente te interesa usarlo, mira el
thread correspondiente en pgsql-general. Creo que el subject era "large
database performance", el que lo inició era Shridar Daithankar y es como
de septiembre/octubre de 2002.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La experiencia nos dice que el hombre peló millones de veces las patatas,
pero era forzoso admitir la posibilidad de que en un caso entre millones,
las patatas pelarían al hombre" (Ijon Tichy)
From | Date | Subject | |
---|---|---|---|
Next Message | rvera | 2003-06-21 16:51:07 | [Pgsql-ayuda] Re: psql -f loco.sql |
Previous Message | rvera | 2003-06-21 14:39:12 | Re: [Pgsql-ayuda] remover PostgreSQL |