Skip site navigation (1) Skip section navigation (2)

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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: OK, that's one LOCALE bug report too many...
Date: 2000-11-24 22:13:44
Message-ID: Pine.LNX.4.21.0011242255460.791-100000@peter.localdomain (view raw, whole thread or download thread mbox)
Lists: 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

> 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

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2000-11-24 22:31:30
Subject: Re: OK, that's one LOCALE bug report too many...
Previous:From: Franck MartinDate: 2000-11-24 21:43:16
Subject: Indexing for geographic objects?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group