Re: character encoding in StartupMessage - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: character encoding in StartupMessage
Date
Msg-id 20060228144453.GC535@svana.org
Whole thread Raw
In response to Re: character encoding in StartupMessage  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: character encoding in StartupMessage
Re: character encoding in StartupMessage
List pgsql-hackers
On Tue, Feb 28, 2006 at 02:45:25PM +0800, Christopher Kings-Lynne wrote:
> >I don't see any very nice solution at the moment.  Once we get support
> >for per-column locales, it might be possible to declare that the shared
> >catalogs are always in UTF8 encoding and get the necessary
> >conversions to happen automatically.
>
> At the very least, could we always convert dbnames and store them as
> their own encoding?  That way at least in HTML you can probably mark
> them out as having particular encodings or something...

This may be the only solution. Converting everything to UTF-8 has
issues because some encodings are not roundtrip-safe (Enc -> UTF8 -> Enc
gives you a different string than you started with). There's probably
no encoding round-trip safe with every other encoding.

You could probably do things like assume that the database name is in
the same encoding as that database and set \l to output:

select convert(datname,pg_encoding_to_char(encoding),getdatabaseencoding()) from pg_database;

However, my personal preference is to treat the name of the database as
a "bunch of bits" ie, don't consider it encoded at all. To login the
user must provide the same "bunch of bits". This doesn't solve the
issue of how to display the database names to users. Maybe define a
cluster encoding for the shared catalogs...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: pg_config, pg_service.conf, postgresql.conf ....
Next
From: "Suvarna"
Date:
Subject: bug in 7.3.2