Re: Locale support is now on by default
От | Tom Lane |
---|---|
Тема | Re: Locale support is now on by default |
Дата | |
Msg-id | 7268.1017813865@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Locale support is now on by default (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Locale support is now on by default
Re: Locale support is now on by default |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > The determination of locale is now done as follows: > initdb --lc-collate, initdb --locale, LC_ALL, LC_COLLATE, LANG > initdb --no-locale is the same as initdb --locale=C, for convenience. I'm confused; what is the default behavior if you don't give any switches to initdb? BTW, something that's been bothering me for awhile is that the notice we stuck into the backend a couple versions back (about "this locale disables LIKE optimizations") is being hidden by initdb, because you decided recently that it was okay to route all the backend's commentary to /dev/null so as to hide xlog.c's startup chattiness. I don't object to getting rid of that chattiness, but 2>/dev/null is throwing the baby out with the bathwater (consider outright failure messages, for instance). It might be that Bruce's recent changes to elog levels allow a graceful compromise about backend messages during initdb. I haven't looked, but maybe initdb could run the backend with message level one notch higher than LOG to suppress all the normal-case messages without masking not- so-normal cases. regards, tom lane
В списке pgsql-hackers по дате отправления: