On 12/02/2010 02:49 AM, Alban Hertroys wrote:
> Because, as opposed to the developers of the projects that you're apparently familiar with, the Postgres developers
havecommon sense ;)
>
> Seriously though, functionality like that has no place in a database server. That's the responsibility of the OS, or
ifit lacks in that respect, for third-party tools.
I can't say I entirely agree with that. PostgreSQL exposes locale names
for input, and it'd be helpful for users to have a way to determine what
the range of accepted input values is. If it was as simple as providing
a proc to list supported locale names, I'd say it'd be worth a few port/
files. However:
Knowing which values are acceptable locale names still doesn't help you
understand what they mean and what their consequences are. You'd also
need a way to get charset names at minimum - and not all OS-supported
charsets are supported by Pg. Pg's confusing "half-in-the-OS,
half-in-the-database-server" charset/collation/encoding handling doesn't
simplify things here.
An alternative would be to provide standard, portable names in Pg and
translate them to OS-specific names. Nobody sane would want to go there
given the choice, though, given that locales on different OSes are
rarely perfectly equivalent. The WINxxx and CPxxx encodings vs LATIN-xx
encodings are only one stumbling point; there are also issues with
differing TZDATA and DST rules and all sorts of other horrors.
So: Listing locales, probably filtered by supported charset(s), would be
nice, but given Pg's current partial dependence on the OS for handling
charset and locale issues, might be as confusing as it is helpful. If Pg
ever gets full locale and collation support internally it'd be a no-brainer.
(Of course, if Pg does its own collation and locale handling later
there'll be issues with inconsistencies between OS and Pg handling.
Argh! You cannot win.)
--
Craig Ringer
