From: | Giles Lean <giles(at)nemeton(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Matthias Urlichs" <smurf(at)noris(dot)de>, MouchaV(at)radiomobil(dot)cz, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Sigh, LIKE indexing is *still* broken in foreign locales |
Date: | 2000-06-08 20:45:21 |
Message-ID: | 5852.960497121@nemeton.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Thu, 08 Jun 2000 10:04:11 -0400 Tom Lane wrote:
> The bounds do not have to be perfectly tight, in the sense of being
> the least string >= or largest string <= the desired strings. It's
> OK if we scan a few extra tuples in some cases. But we have to have
> reasonably close bounds or we can't implement LIKE with an index.
Determining the bounding (sub-)strings looks like a very hard problem.
I think there is enough information in a POSIX locale to determine
what the rules for constructing such bounds would be ... but there is
no programatic interface to determine the rules a locale uses for
collation. (I have no idea what non-POSIX systems provide.)
(The localedef program can build a locale. strcoll() and strxfrm()
can use the collation information. That's all I see.)
In the absence of a way to do this "right" we need someone to see a
"good enough" hack that happens to work everywhere, or else give up
using indexes for LIKE which I doubt would please anyone. I suppose
the mismatch comes about because LIKE is about pattern matching and
not collation. :(
Regards,
Giles
From | Date | Subject | |
---|---|---|---|
Next Message | Erich Stamberger | 2000-06-09 00:25:52 | Re: Sigh, LIKE indexing is *still* broken in foreign locales |
Previous Message | Tom Lane | 2000-06-08 14:04:11 | Re: Sigh, LIKE indexing is *still* broken in foreign locales |
From | Date | Subject | |
---|---|---|---|
Next Message | Don Baccus | 2000-06-08 21:19:09 | Re: Proposal: TRUNCATE TABLE table RESTRICT |
Previous Message | Tom Lane | 2000-06-08 19:52:43 | Re: DROP COLUMN status |