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/
