Re: check_locale() and the empty string
От | Jeff Davis |
---|---|
Тема | Re: check_locale() and the empty string |
Дата | |
Msg-id | 1332704612.8251.11.camel@jdavis обсуждение исходный текст |
Ответ на | Re: check_locale() and the empty string (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: check_locale() and the empty string
|
Список | pgsql-bugs |
On Sat, 2012-03-24 at 19:07 -0400, Tom Lane wrote: > Jeff Davis <pgsql@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. > I do agree that it's probably unwise to store an empty string as the > value of pg_database.datcollate or datctype, because that would mean > that if the server is restarted with different LC_XXX environment values > then it will think the database has different locale settings, leading > to havoc. Yes, that's the worst of the problem. I should have mentioned that more explicitly in the original report. > However, ISTM the right fix is to replace an empty-string > value with the implied locale name at createdb time. Proposed patch > attached. +1. > 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. Regards, Jeff Davis
В списке pgsql-bugs по дате отправления: