RE: Locale by default?
От | Zeugswetter Andreas SB SD |
---|---|
Тема | RE: Locale by default? |
Дата | |
Msg-id | 46C15C39FEB2C44BA555E356FBCD6FA41EB381@m0114.s-mxs.net обсуждение исходный текст |
Ответ на | Locale by default? (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
> > 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
В списке pgsql-hackers по дате отправления: