From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Progress report on locale safe LIKE indexing |
Date: | 2001-08-19 23:52:12 |
Message-ID: | 3B80512C.36296697@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut wrote:
>
> Hiroshi Inoue writes:
>
> > Hmm * string1 = string2 * doesn't imply * string1 LIKE string2 * ?
>
> In the current implementation of LIKE, you're right. The SQL standard
> allows for the possibility that "[d]epending on the collating sequence,
> two strings may compare as equal even if they are of different lengths or
> contain different sequences of characters." However, I doubt that this
> can really happen in practice. For example, in some collating sequences
> (such as en_US), characters with diacritic marks (accents) are "more
> equal" than others, but in the end there's always a tie breaker. Or do
> you know an example where this really happens?
I can see the examples in a documentation M$ SQL Server though
I can't try it in reality.
For example
ignore case(low/high)
ignore accents
I don't think they are strange as collating sequences.
You are establishing a pretty big mechanism and I think
you should clarify the assumption.
Please tell me the assumption.
I can think of the followings.
1) Because the current implementaion of LIKE isn't locale-aware,
we should be compatible with it for ever.
2) strcoll(str1, str2) == 0 means strcmp(str1, str2) == 0
in any locale.
regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Grant | 2001-08-20 00:11:48 | Re: DB size |
Previous Message | Naomi Walker | 2001-08-19 23:09:23 | Tool Search |