Re: [HACKERS] Bug in LIKE ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Daniele Orlandi <daniele(at)orlandi(dot)com>, pgsql-hackers(at)hub(dot)org, The Hermit Hacker <scrappy(at)hub(dot)org>
Subject: Re: [HACKERS] Bug in LIKE ?
Date: 1999-06-07 15:33:04
Message-ID: 25004.928769584@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
>> Anyway, it's fixed now. I also cleaned up some confusion about whether
>> "%%" in a LIKE pattern means a literal % (the SQL spec says not, and
>> some parts of the code knew it, but other parts didn't...)

> Yeah, but until we have support for the ESCAPE clause on the LIKE
> expression then there isn't a way to get a literal "%" into the query
> :(

Sure there is: \%. Of course, defaulting to ESCAPE \ rather than no
escape is not standards-compliant either, but it's a lot closer than
inventing a meaning for %% ...

More to the point, %% has not worked like gram.y thought it did for
a long time, if ever, and no one's complained ...

> imho we will eventually need to move all of this out of gram.y and put
> it deeper into the parser code, since it is munging the query so early
> it is difficult to know what was done for later stages.

Agreed. At the very least it should be postponed until we know that the
operator in question *is* textlike(), and not something else that
happens to be named ~~ ... but that's a job for another day.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-06-07 15:35:35 Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y'
Previous Message Bruce Momjian 1999-06-07 15:32:50 Re: [HACKERS] LO Problem List (Can we get one)