> -Original Message-
> From: Peter Eisentraut
>
> Hiroshi Inoue writes:
>
> > If your solution is short-lived, your change would be not
> > only useless but also harmful. So I expect locale-aware
> > people to confirm that we are in the right direction.
>
> I am a bit confused here. We ha
Zeugswetter Andreas SB SD writes:
> > I am a bit confused here. We have tinkered with LIKE indexing at
> least a
> > year. Now that a solution is found that *works*, it is claimed that
> it is
> > harmful because LIKE was doing the wrong thing in the first place.
> OTOH,
> > I have not seen any
> > If your solution is short-lived, your change would be not
> > only useless but also harmful. So I expect locale-aware
> > people to confirm that we are in the right direction.
>
> I am a bit confused here. We have tinkered with LIKE indexing at
least a
> year. Now that a solution is found
Hiroshi Inoue writes:
> If your solution is short-lived, your change would be not
> only useless but also harmful. So I expect locale-aware
> people to confirm that we are in the right direction.
I am a bit confused here. We have tinkered with LIKE indexing at least a
year. Now that a solution
Peter Eisentraut wrote:
>
> Hiroshi Inoue writes:
>
> > 1) Because the current implementaion of LIKE isn't locale-aware,
> >we should be compatible with it for ever.
>
> I'm not sure I intended to say that. The combination of the following
> factors seems important:
>
> a) compatibility is
Hiroshi Inoue writes:
> 1) Because the current implementaion of LIKE isn't locale-aware,
>we should be compatible with it for ever.
I'm not sure I intended to say that. The combination of the following
factors seems important:
a) compatibility is desirable
b) no requests to the contrary ha
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 compa
Tom Lane writes:
> But the LIKE code does know about multibyte character sets. Is it safe
> to assume that memcmp-based sorting will not make any mistakes with
> multibyte characters?
Remember that this memcmp-based sorting is the same sorting that texteq
will do when locale is turned off. So
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 differen
> -Original Message-
> From: Peter Eisentraut
>
> Hiroshi Inoue writes:
>
> > Please look at my first question.
> >This depends on the assumption that '=' is equivalent in
> >any locale. Is it guaranteed ?
> >For example, ( 'a' = 'A' ) isn't allowed in any locale ?.
> >
> > And
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Now, if you look at the code that does the LIKE pattern matching you'll
> see that it does not use any locale features, it simply compares
> characters for equality based on their character codes, accounting for the
> wildcards. Consequentially, this
Hiroshi Inoue writes:
> Please look at my first question.
>This depends on the assumption that '=' is equivalent in
>any locale. Is it guaranteed ?
>For example, ( 'a' = 'A' ) isn't allowed in any locale ?.
>
> And your answer was
>The whole point here is not to rely on '='.
>
> C
> -Original Message-
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue writes:
>
> > Isn't 'a' LIKE 'A' if 'a' = 'A' ?
>
> Yes. But 'a' <> 'A'.
Please look at my first question.
This depends on the assumption that '=' is equivalent in
any locale. Is it guaran
Hiroshi Inoue writes:
> Isn't 'a' LIKE 'A' if 'a' = 'A' ?
Yes. But 'a' <> 'A'.
> LIKE seems to use the collating sequence.
No. The collating sequence defines the order of all possible strings.
LIKE doesn't order anything.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net
> -Original Message-
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue writes:
>
> > > An operator class text_binary_ops that does memcmp()-based
> comparison of
> > > text data. The operators are named $<$ etc. for lack of a
> better idea.
> > > That lack is further i
Hiroshi Inoue writes:
> > An operator class text_binary_ops that does memcmp()-based comparison of
> > text data. The operators are named $<$ etc. for lack of a better idea.
> > That lack is further illustrated by the idea to name them "binary-<" etc.,
> > which wouldn't get through the parser,
Peter Eisentraut wrote:
>
> I have so far implemented the following:
>
> An operator class text_binary_ops that does memcmp()-based comparison of
> text data. The operators are named $<$ etc. for lack of a better idea.
> That lack is further illustrated by the idea to name them "binary-<" etc.,
17 matches
Mail list logo
