> > 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.
Yup, imho we all understood that and the only (to be validated) concern
is
performance.
>
> 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.,
Yes, that was the (or at least my) main concern.
> 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?
I think that's it :-)
Andreas
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
