From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | "Arturo Munive [pgsql-es-ayuda]" <arturomunive(at)gmail(dot)com> |
Cc: | Mario Wojcik <mariowojcik(at)yahoo(dot)com(dot)ar>, Lista de Ayuda Postgresql <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Collations Sequense (o algo así) |
Date: | 2007-08-03 21:08:30 |
Message-ID: | 20070803210830.GB20254@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Arturo Munive [pgsql-es-ayuda] escribió:
> Mario Wojcik escribió:
>> Para mi que es saña de Alvaro hacia mis conclusiones tratando de
>> obligarme a leer el manual en ingles!!! Je je
>>
> mmm no se, pero sería bueno despejar esa duda, a que parte del manual te
> refieres????
Mira en 21.2.2. Setting the Character Set (en el capitulo Localization)
Important: Although you can specify any encoding you want for a
database, it is unwise to choose an encoding that is not what is
expected by the locale you have selected. The LC_COLLATE and
LC_CTYPE settings imply a particular encoding, and locale-dependent
operations (such as sorting) are likely to misinterpret data that is
in an incompatible encoding.
Since these locale settings are frozen by initdb, the apparent
flexibility to use different encodings in different databases of
a cluster is more theoretical than real. It is likely that these
mechanisms will be revisited in future versions of PostgreSQL.
One way to use multiple encodings safely is to set the
locale to C or POSIX during initdb, thus disabling any real
locale awareness.
--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"La gente vulgar solo piensa en pasar el tiempo;
el que tiene talento, en aprovecharlo"
From | Date | Subject | |
---|---|---|---|
Next Message | Matias Ocampo/GOBCBA | 2007-08-03 21:09:59 | Re: Cambiar de VARCHAR a NUMERIC |
Previous Message | Alvaro Herrera | 2007-08-03 21:05:56 | Re: Cambiar de VARCHAR a NUMERIC |