Jeff Davis <pg...@j-davis.com> writes: > On Sat, 2012-03-24 at 19:07 -0400, Tom Lane wrote: >> Jeff Davis <pg...@j-davis.com> writes: >>> Surely we don't want it to be set from the environment, right?
>> Why not? > I agree that we shouldn't change the documented behavior of those GUCs. > But a SQL command like CREATE DATABASE being environment sensitive does > seem like surprising behavior to me, and it did indirectly > lead to a bug. Well, our locale documentation makes it pretty clear that a lot of this behavior is inherited from the server's environment by default: http://www.postgresql.org/docs/devel/static/locale.html So I don't see anything wrong with that in principle. But we'd better make sure that a database's lc_collate/lc_ctype are locked down after creation. >> Note 2: there is code in initdb that is supposed to be kept parallel >> to this, but it's not currently making any attempt to canonicalize >> non-empty locale names. Should we make it do that too? > I assume you are talking about the code that results in writing the > settings to postgresql.conf? > It doesn't look quite as dangerous in that area because (a) it ignores > zero-length strings; and (b) setting the GUC to the wrong value will > either be prevented or will not cause any major problem. However, it > does seem like a good idea to canonicalize the settings unless there is > some reason not to. When I wrote the proposed patch, I was imagining that setlocale() would in fact do some canonicalization of the supplied string. Experimentation shows that's not so, though, at least not on current Linux and OS X: you seem to get back the supplied string in all cases except where it's "". The reason I was hoping for canonicalization is that right now we consider locale names like "en_US.utf8" and "en_US.UTF-8" to be different, even though libc very probably treats them the same; this results in CREATE DATABASE rejecting lc_collate/ctype settings that are only cosmetically different from the template database's values. Canonicalization by setlocale() would fix that without requiring us to make any unsupported assumptions about which names mean the same. Oh well. However, it might still be that somewhere there is a libc that does take the opportunity to canonicalize the locale name, and if that did happen then it would be important for initdb to do it the same way as CREATE DATABASE does. Otherwise, we might end up rejecting a CREATE DATABASE lc_collate/ctype setting that's identical to what the user told initdb to use, because one got canonicalized and the other not. So this roundabout series of assumptions leads me to think that initdb needs to be tweaked too. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs