Tom Lane wrote:
>
> * Fix LIKE indexing optimization for non-ASCII locales
>
> I've applied a brute-force solution, which is not to do any LIKE
> optimization in non-ASCII locales :-(.
What is a non-ASCII locale ? Anything that is not LC_ALL=ASCII ?
BTW, it would really help if we had a way to query for locale at
runtime,
like SELECT CURRENT_LOCALE();
How should one find out which locale we are in ?
From your comment above I assume that you know it ;)
> This is not an ideal answer,
> but perhaps the TODO item should read more like "Figure out how to
> do LIKE indexing optimization in non-ASCII locales".
I think that the cleanest solution should be to define our own locales
that can be doctored to satisfy the LIKE optimisation requirements.
We will probably need something like that in the future anyway as AFAIK
SQL 9x requires ability to have locales applicable on field-to-field
basis
not just one per host.
-------------
Hannu
