On Wed, Jun 17, 2015 at 01:43:55PM -0400, Tom Lane wrote: > Noah Misch <n...@leadboat.com> writes: > > On Mon, Jun 15, 2015 at 12:37:43PM -0400, Tom Lane wrote: > >> It's mere chance that the order of calls to pg_perm_setlocale() is > >> such that the code works now; and it's not hard to imagine future > >> changes in gettext, or reordering of our own code, that would break it. > > > pg_bind_textdomain_codeset() looks at one piece of the locale environment, > > namely setlocale(LC_CTYPE, NULL), so the order of pg_perm_setlocale() calls > > does not affect it. > > Well, my point is that that is a larger assumption about the behavior of > pg_bind_textdomain_codeset() than I think we ought to make, even if it > happens to be true today.
Perhaps it's just me, but I can envision changes of similar plausibility that break under each approach and not the other. Without a way to distinguish on that basis, I'm left shrugging about a proposal to switch. For that matter, if pg_bind_textdomain_codeset() starts to act on other facets of the locale, that's liable to be a bug independent of our choice here. However locale facets conflict, we expect LC_CTYPE to control the message codeset. > > There's nothing acutely bad about the alternative you > > identify here, but it's no better equipped to forestall mistakes. Moving > > the > > call later would slightly expand the window during which translated messages > > are garbled. > > 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
