Skip site navigation (1) Skip section navigation (2)

RE: initdb -E LATIN9 no funciona

From: "Javier Aquino H(dot)" <JAquino(at)LexusEditores(dot)com>
To: "'Alvaro Herrera'" <alvherre(at)commandprompt(dot)com>, "'Gunnar Wolf'" <gwolf(at)gwolf(dot)org>
Cc: "'pgsql-es-ayuda'" <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: RE: initdb -E LATIN9 no funciona
Date: 2010-09-24 17:52:49
Message-ID: !&!AAAAAAAAAAAYAAAAAAAAAM2s7SGV8UJPhOCUGX7igBnCgAAAEAAAABhm3TMYPGxLm4NcKcoG+ZsBAAAAAA==@LexusEditores.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
-----Mensaje original-----
De: Alvaro Herrera [mailto:alvherre(at)commandprompt(dot)com] 
Enviado el: viernes, 24 de septiembre de 2010 09:46 a.m.
Para: Gunnar Wolf
CC: Javier Aquino H.; pgsql-es-ayuda
Asunto: Re: [pgsql-es-ayuda] initdb -E LATIN9 no funciona

Excerpts from Gunnar Wolf's message of vie sep 24 09:07:51 -0400 2010:

> > Y funcionó, pero tengo una duda, habrá algún degrado de performance al tener LC_COLLATE y LC_CTYPE en 'C' ????
> 
> No. Las operaciones de costumbre son sólo de almacenamiento,
> comparación, envío... Claro, la cadena va a ser muy ligeramente más
> larga. Pero en nuestro idioma, la diferencia es bajísima. 

Hay un par de operaciones que están optimizadas para codificaciones que
tienen máximo largo de carácter de uno (es decir, no multibyte).  Pueden
ser un pelín más lentas en UTF8.  Pero concuerdo con Gunnar en que es
mucho mejor usar UTF8.

> > Valdrá la pena usar UTF8 (que almacena entre 1 y 4 bytes por
> > carácter) o LATIN9 (1 byte por carácter) pero con LC_COLLATE y
> > LC_CTYPE en 'C' ????? que es mejor ????
> 
> Ummm... Bueno, no entiendo bien a qué te refieres. En general, C
> significa "por default, si no especificaste nada" - Lo cual tiende a
> significar en_US.ASCII. Pero en este último punto puedo estar
> equivocado.

Lo que sucede es que Postgres distingue las dos cosas con mucha
claridad, que en el resto de los sistemas tienden a mezclarse y
confundirse como si fueran una sola: la codificación y el locale
(que en nuestra traducción llamamos “configuración regional”).  Una
configuración regional de en_US.utf-8 indica que el locale propiamente
tal es en_US (es decir usando las reglas del inglés de EEUU para
ordenamiento de cadenas, formato de fechas y dinero, etc) y que usa
codificación UTF-8.  A diferencia del locale en_US, que en estricto
rigor significa en_US.ISO8859-1, que usa las mismas reglas del inglés de
EEUU pero con codificación Latin1 (más formalmente conocido como
ISO-8859-1).

En Postgres, por motivos de implementación, sólo se te permite usar una
codificación dentro del cluster de bases de datos que sea compatible con
el locale definido.  Es decir, si tu cluster lo definiste como es_PE
(que, como ya dije, se refiere a es_PE.ISO8859-1), entonces todas las
bases de datos deben ser Latin1.  Existe una excepción, mencionada en la
documentación de CREATE DATABASE:

	The character set encoding specified for the new database must
	be compatible with the chosen locale settings (LC_COLLATE and
	LC_CTYPE). If the locale is C (or equivalently POSIX), then all
	encodings are allowed, but for other locale settings there is
	only one encoding that will work properly.

Es decir se te permite crear una BD UTF8 en un cluster Latin1, siempre y
cuando definas el locale a C.  Es posible que esto tenga efectos
secundarios no deseados: por ejemplo puede ser (no tengo claridad que
sea así) que el ordenamiento de cadenas de caracteres no sea el español.

-----FIN Mensaje original-----

Gracias a todos por los aportes, al final voy a usar UTF8 que aun que es "un pelín" más lento (como lo dijera Alvaro) resulta siendo lo mejor para mantener la compatibilidad.

Gracias nuevamente a todos por sus aportes.

Saludos y pasen un buen fin de semana.

Javier.



In response to

pgsql-es-ayuda by date

Next:From: Miguel Angel Hernandez MorenoDate: 2010-09-24 23:44:21
Subject: select anidado con parseo
Previous:From: Gilberto Castillo MartínezDate: 2010-09-24 15:20:20
Subject: Re:

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group