From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Zoltan Boszormenyi <zb(at)cybertec(dot)at> |
Cc: | PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Hans-Juergen Schoenig <hs(at)cybertec(dot)at> |
Subject: | Re: [RFC] Localized literals |
Date: | 2008-04-23 08:46:45 |
Message-ID: | 20080423084645.GC16761@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 23, 2008 at 10:02:37AM +0200, Zoltan Boszormenyi wrote:
> But the question popped up whether PostgreSQL can be extended
> to allow localized literals and apply encoding conversion the same
> way as on string data. NAMEDATA can be replaced with regular TEXT
> and have the same conversion everywhere. This way the relation and
> field name limits are also eliminated. The conversion could be controlled
> by a compile-time option and/or a GUC variable. Tell me if I am crazy.
It does convert the table names also, since the encoding translation is
applied to the whole query string, not just normal strings. A simple
SET CLIENT_ENCODING='latin9' at the beginning of your dump should have
worked.
As for the other point, the reason NAMEDATA is fixed is because these
records is mapped onto in memory structures in the backend. By changing
it to a variable length type all structure accesses would become much
more expensive.
But none of this has anything ot do with encodings.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-04-23 09:18:56 | Re: pgkill on win32 |
Previous Message | Zoltan Boszormenyi | 2008-04-23 08:02:37 | [RFC] Localized literals |