> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org 
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
> Sent: Tuesday, June 15, 2004 12:04 PM
> To: Peter Eisentraut
> Cc: Christopher Kings-Lynne; Hackers
> Subject: Re: [HACKERS] #postgresql report 
> 
> 
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Christopher Kings-Lynne wrote:
> >> * We have a request for how to change database encoding 
> every other 
> >> day
> 
> > This is pretty much impossible.  It's analogous to 
> changing, say, the
> > endianness of all integers.  You would need to rewrite the entire 
> > database.  But pg_dump & restore already does that.
> 
> I wonder though, do the requestors actually know what they're 
> asking for? Are they really asking for encoding changes, or 
> are they asking for locale changes?
> 
> >> (i suggest a warning in initdb if no encoding is specified - EVERY 
> >> pgsql newbie fails to set it)
> 
> > Hm...
> 
> initdb already tells you pretty clearly what locale it's 
> picking. I think people don't read the message and/or don't 
> understand the implications.
> 
> IMHO the *real* issues here boil down to two things:
> 
> 1. You can't change locale after initdb.  Even a per-database 
> locale setting would be better than that (though of course 
> the SQL spec sets the bar much higher, namely per-column locales).

How about (at least) a per object locale setting as a goal?

Have a system table that tracks it.  The system table could be flexible
enough to describe objects of any sort (tables, stored procedures...)
and perhaps be extended to columns eventually.

I can't think of any time I wanted more than one locale in a single
table (and think of how confusing it could become to have 19 different
locales in a single table, expecially if some of the users were not
aware of them).  But sometimes, a different locale for different tables
can be very useful [e.g. processing orders from different countries].
Actually, I am used to having different codepages, but I imagine that
maps to different locales directly.  It seems that the inheritance of
PostgreSQL might be nice to implement this feature in a natural way.

E.g.
NorwegianAddress inherits from Address, but sets the codepage for
Norway.

And things like FrenchAddress would know about 'Rue' instead of
'Street', etc.

> 2. You can shoot yourself in the foot by selecting a database 
> encoding that's not compatible with the (fixed) locale.
> 
> AFAICS there is not very much we can do about either of these 
> things without creating our own locale support layer so we 
> can stop depending on the standard C library's inflexible and 
> taciturn API.
> 
> Peter has mentioned that he is working on that but that it 
> might be a year or so before it's ready.  Is that still a 
> reasonable guess?
> 
> 			regards, tom lane
> 
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to 
> majordomo@postgresql.org)
> 

Tue, 15 Jun 2004 12:42:16 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: #postgresql report 