Re: OK, that's one LOCALE bug report too many...
От | Peter Eisentraut |
---|---|
Тема | Re: OK, that's one LOCALE bug report too many... |
Дата | |
Msg-id | Pine.LNX.4.21.0011242255460.791-100000@peter.localdomain обсуждение исходный текст |
Ответ на | OK, that's one LOCALE bug report too many... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: OK, that's one LOCALE bug report too many...
|
Список | pgsql-hackers |
Tom Lane writes: > I propose, therefore, that in an --enable-locale installation, initdb > should save its values for LC_COLLATE and LC_CTYPE in pg_control, and > backend startup should restore these settings from pg_control. Note that when these are unset there might still be a "catch-all" locale value coming from the LANG env. var. (or LC_ALL on some systems). > Also, since "LC_COLLATE=en_US" seems to misbehave rather spectacularly > on recent RedHat releases, I propose that initdb change "en_US" to "C" > if it finds that setting. (Are there any platforms where there are > non-bogus differences between the two?) There *should* be differences and it is definitely not okay to mix them up. > Finally, until we have a really bulletproof solution for LIKE indexing > optimization, I will disable that optimization if --enable-locale is > compiled *and* LC_COLLATE is not C. Better to get "LIKE is slow" bug > reports than "LIKE gives wrong answers" bug reports. (C or POSIX) I have a question about that optimization: If you have X LIKE 'foo%', wouldn't it be enough to use X >= 'foo' (which certainly works for any locale I've ever heard of)? Why do you need the X <= 'foo???' at all? > Comments? Anyone think that initdb should lock down more categories > than just these two? Not sure whether LC_CTYPE is necessary. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: