From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Sullivan <andrew(at)libertyrms(dot)info>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: default locale considered harmful? (was Re: [GENERAL] |
Date: | 2003-04-20 16:16:20 |
Message-ID: | Pine.LNX.4.44.0304201725360.2891-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Tom Lane writes:
> I recall someone floating a proposal that initdb should by default
> initialize the database in C locale, not whatever-it-finds-in-the-
> environment. To get a non-C locale you'd have to give an explicit
> command-line switch --- essentially, reversing the sense of the present
> "initdb --no-locale" option.
If you're concerned about speed, let's think about fixing the real
problems, not about disabling the feature altogether. A while ago I
proposed an easy solution that made LIKE use an index based on strxfrm
order instead. It was rejected on the grounds that it would prevent a
future enhancement of the LIKE mechanism to use the locale-enabled
collation order, but no one seems to be seriously interested in
implementing that. I still have the patch; we can reconsider it if you
like.
(Btw., LIKE using the locale-enabled collation sequence is hardly going to
work, because most locales compare strings backwards from the end to the
start in the second pass, so something like LIKE 'foo%' can easily give
inconsistent results, since you don't know what the end of the string
really is. It's better to think of pattern matching as
character-by-character matching.)
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2003-04-20 16:46:09 | Re: [SQL] Yet Another (Simple) Case of Index not used |
Previous Message | Andreas Pflug | 2003-04-20 15:37:57 | Re: [SQL] Yet Another (Simple) Case of Index not used |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-04-20 16:16:46 | Re: rename/unlink handling for Win32 |
Previous Message | Stephan Szabo | 2003-04-20 16:04:10 | Re: [PERFORM] Foreign key performance |