Thread: Re: [GENERAL] escaping wildcard chars
At 08:16 +0300 on 26/07/1999, Dan Wilson wrote: > SELECT typname from pg_type WHERE NOT LIKE '_%' > > It gives me an empty set. > > Is there any way to escape the underscore. I tried to use '\_%', but that > didn't help. Any suggestions? Yes. Use '\\_%' instead. You see, a backslash is interpreted immediately as "take the next char literally". This passes the underscore literally to LIKE. Which is the same as '_%'. If you put a double backslash, the first backslash takes the second one literally, thus passing '\_%' to LIKE. And then LIKE knows that it should treat the underscore as non-special. Ugly, ugly. I think we had a discussion either here or in one of the other lists regarding the ESCAPE clause to LIKE. This behavior means that even if we write ESCAPE '\', it won't work (Actually, it should be '\\'. I really hate those backslashes. They are blatantly incompatible with SQL92 and will cause standard SQL to fail on Postgres, (and of course, Postgres code to fail on other databases). There should be a setting, either in the backend or in a SET command, such as "BACKSLASH_BEHAVIOR", which will be either "literal" or "escape". It can default to the current behavior (namely "escape") so that current code won't fail, but will enable people to write sane standard code. Herouth -- Herouth Maoz, Internet developer. Open University of Israel - Telem project http://telem.openu.ac.il/~herutma
> Yes. Use '\\_%' instead. You see, a backslash is interpreted immediately as > "take the next char literally". This passes the underscore literally to > LIKE. Which is the same as '_%'. If you put a double backslash, the first > backslash takes the second one literally, thus passing '\_%' to LIKE. And > then LIKE knows that it should treat the underscore as non-special. I tried this and it didn't work either. I eventually got carried away and did '\\\_%' and it worked. What a pain! > I really hate those backslashes. They are blatantly incompatible with SQL92 > and will cause standard SQL to fail on Postgres, (and of course, Postgres > code to fail on other databases). There should be a setting, either in the > backend or in a SET command, such as "BACKSLASH_BEHAVIOR", which will be > either "literal" or "escape". It can default to the current behavior > (namely "escape") so that current code won't fail, but will enable people > to write sane standard code. I totally agree here. There should be some way to turn it off so that those who are starting out can write standard stuff. -Dan
> I really hate those backslashes. They are blatantly incompatible with SQL92 > and will cause standard SQL to fail on Postgres, (and of course, Postgres > code to fail on other databases). There should be a setting, either in the > backend or in a SET command, such as "BACKSLASH_BEHAVIOR", which will be > either "literal" or "escape". It can default to the current behavior > (namely "escape") so that current code won't fail, but will enable people > to write sane standard code. Thanks for the info and I totally agree. There should be some type of way to turn it off or on. -Dan