Peter Eisentraut wrote:
>
> Tom Lane writes:
>
> > Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > > Just to understand things correctly. Is the Like optimization disabled
> > > for all non-ASCII char sets, or (imho correctly) for non charset ordered
> > > collations (LC_COLLATE) ?
> >
> > Currently it's disabled whenever LC_COLLATE is neither C nor POSIX.
> > We can add other names to the "OK" list as we verify that they are safe
> > (see locale_is_like_safe() in src/backend/utils/adt/selfuncs.c).
>
> I have pretty severe doubts that any locale for a language that uses the
> Latin, Cyrillic, or Greek alphabets (i.e., those that are conceptually
> similar to English) is like-optimization safe (for the optimization
> algorithm in its current state), at least across all platforms.
> Somewhere a vendor is going to adhere to some ISO standard and implement
> the same multi-pass "letters first" rules that we observed in en_US.
Is there any possibility to use, in a portable way, only our own locale
definition files, without reimplementing all the sorts uppercases etc. ?
If we had control over the locale definition contents we would be much
better
off when optimizing as well.
And IIRC SQL9x prescribe support for multiple locales (or at least
multiple
collating sequences) within one database simultaneously.
> There should be some extensive "stress test" that a locale should have to
> pass before being labelled safe.
Sure.
-------------
Hannu
