Re: OK, that's one LOCALE bug report too many...

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(at)gmx(dot)net http://yi.org/peter-e/