Tom Lane wrote:
I think it's just a bug in 8.3.
Well, here's a patch that I think fixes it. If you're happy I'll apply
it to HEAD and 8.3.
cheers
andrew
? .deps
Index: like_match.c
===
RCS file:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's just a bug in 8.3.
Well, here's a patch that I think fixes it. If you're happy I'll apply
it to HEAD and 8.3.
That patch isn't gonna apply to HEAD ;-). Also the introduction of
NextChar is simply broken, as it will skip
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's just a bug in 8.3.
Well, here's a patch that I think fixes it. If you're happy I'll apply
it to HEAD and 8.3.
That patch isn't gonna apply to HEAD ;-). Also the introduction of
Andrew Dunstan [EMAIL PROTECTED] writes:
I'll have another look. What happens in that case though if you have
escape+x where x is a multibyte char?
TCHAR()'s just a no-op in multibyte encodings --- we handle ILIKE
using a preliminary downcasing pass in that case.
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I'll have another look. What happens in that case though if you have
escape+x where x is a multibyte char?
TCHAR()'s just a no-op in multibyte encodings --- we handle ILIKE
using a preliminary downcasing pass in that case.
Good:
regression=# select 'T' ilike 't';
?column?
--
t
(1 row)
Not so good:
regression=# select 'T' ilike E'\\t';
?column?
--
f
(1 row)
ISTM backslash is only supposed to turn off the pattern-language
specialness of characters, not render them case sensitive. The reason
Tom Lane wrote:
Good:
regression=# select 'T' ilike 't';
?column?
--
t
(1 row)
Not so good:
regression=# select 'T' ilike E'\\t';
?column?
--
f
(1 row)
ISTM backslash is only supposed to turn off the pattern-language
specialness of characters, not render them case
Andrew Dunstan [EMAIL PROTECTED] writes:
The docs actually don't state what are the semantics of escape followed
by something that is not escape or a metachar. Does the spec say
anything about that?
The spec says it's an error, per the SQL92 excerpt I quoted in the
previous thread. (SQL99
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The docs actually don't state what are the semantics of escape followed
by something that is not escape or a metachar. Does the spec say
anything about that?
The spec says it's an error, per the SQL92 excerpt I quoted in the
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
So I'm for the definition that escape-anything means exactly anything,
without any special treatment that it would otherwise have. And in
the case of ILIKE it seems like no special treatment should mean
case insensitive match.
Well,
On Sep 25, 2008, at 20:45, Tom Lane wrote:
Well, there are two possible interpretations: (1) it's a bug, or (2)
it's an intentional, about-to-be-documented feature that
backslashing a
letter makes it case-sensitive in ILIKE.
I do not care for interpretation #2 ... especially in view of your
Christopher Kings-Lynne wrote:
Hi,
I have just tried using the ILIKE function in 7.0.3. I assume that it is
just a case-insensitive version of LIKE. (Please correct me if I am wrong
on this assumption.)
AFAIK postgres 7.0.3 does not have it, ILIKE appeared in 7.1
But you could use
Christopher Kings-Lynne writes:
I have just tried using the ILIKE function in 7.0.3.
There is no ILIKE function in 7.0.3.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Hi,
I have just tried using the ILIKE function in 7.0.3. I assume that it is
just a case-insensitive version of LIKE. (Please correct me if I am wrong
on this assumption.)
This is my example test case:
usa=# select 'test' LIKE '%es%';
?column?
--
t
(1 row)
usa=# select 'test'
14 matches
Mail list logo
