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 [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
