Re: Locale by default?

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: <Inoue(at)tpf(dot)co(dot)jp>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Locale by default?
Date: 2001-08-22 15:50:32
Message-ID: Pine.LNX.4.30.0108221741150.679-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii writes:

> I don't understand why you object the idea giving PostgreSQL the
> ability to turn off the locale support in configuration/compile
> time. In that way, there's no inconveniences for "many users".

I don't mind at all the ability to turn it off. My point is that the
compile time is the wrong time to do it. Many users use binary
packages these days, many more users would like to use binary packages.
But the creators of these packages have to make configuration choices to
satisfy all of their users. So they turn on the locale support, because
that way if you don't want it you can turn if off. The other way around
doesn't work.

The more appropriate way to handle this situation is to make it a runtime
option. I agree that the LC_ALL/LC_COLLATE/LANG lattice is confusing and
fragile. But there can be other ways, e.g.,

initdb --locale=en_US
initdb --locale-collate=C --locale-ctype=en_US
initdb # defaults to --locale=C

or in postgresql.conf

locale=C
locale_numeric=en_US
etc.

or

SHOW locale;
SHOW locale_numeric;

That way you always know exactly what situation you're in. I think this
was Hiroshi's main concern, the reliance on export LC_ALL, and I agree
that this is bad.

You say locale in Japan works, except for LC_COLLATE. This concern would
be satisfied by the above approach.

Comments?

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lamar Owen 2001-08-22 15:52:15 Re: Link to bug webpage
Previous Message Tom Lane 2001-08-22 15:39:52 Re: GiST patches for 7.2 (please apply)