Re: How to find correct locale name for CREATE DATABASE

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
Cc: Andrus <kobruleht2(at)hot(dot)ee>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Thom Brown <thom(at)linux(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: How to find correct locale name for CREATE DATABASE
Date: 2010-12-02 00:54:39
Message-ID: 4CF6EE4F.5090400@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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 have common sense ;)
>
> Seriously though, functionality like that has no place in a database server. That's the responsibility of the OS, or if it 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2010-12-02 03:15:55 Re: Proper Permissions for /usr/local/pgsql/data
Previous Message Craig Ringer 2010-12-02 00:42:37 Re: Looking for auto starting procedures