Re: #postgresql report - Mailing list pgsql-hackers

> -----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)
>