Re: "could not adopt C locale" failure at startup on Windows
От | Tom Lane |
---|---|
Тема | Re: "could not adopt C locale" failure at startup on Windows |
Дата | |
Msg-id | 3561.1434637915@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: "could not adopt C locale" failure at startup on Windows (Noah Misch <noah@leadboat.com>) |
Список | pgsql-hackers |
Noah Misch <noah@leadboat.com> writes: > On Wed, Jun 17, 2015 at 01:43:55PM -0400, Tom Lane wrote: >> I'm not exactly sure that they wouldn't be garbled anyway during the >> interval where we're setting these things up. Until DatabaseEncoding, >> ClientEncoding, and gettext's internal notions are all in sync, we >> are at risk of that type of issue no matter what. > True; the window exists and is small enough both ways. This is merely one > more reason to fix the bug without fixing what ain't broke. [ shrug... ] I'm not planning to waste a whole lot more breath on this topic, but to my mind the current definition of pg_perm_setlocale() *is* broke. Previously, that function only interacted with the standard libc locale facilities. Now it's also entangled with gettext(), as well as SetMessageEncoding and GetDatabaseEncoding. IMO that extra cross-module entanglement is the exact reason we have a bug here. It's a layering violation and I think we should get rid of it. regards, tom lane
В списке pgsql-hackers по дате отправления: