Skip site navigation (1) Skip section navigation (2)

Re: LIKE wildcards escaping problem

From: Thea <monika(dot)morawiecka(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: LIKE wildcards escaping problem
Date: 2007-09-24 13:10:49
Message-ID: 1190639449.078452.64590@g4g2000hsf.googlegroups.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Yes, I always tend to mix slash and backslash. No idea why ^^'.
Postgres version is:

PostgreSQL 8.2.4 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC)
3.4.2 (mingw-special)

and it does have this setting, but it was set to off.
Now, having this set I'll have to test it :)
Thank you for your ansewrs and for directing me to proper group, I'll
ask such questions in -general in future.
Again, thank you a lot.

regards,
Thea


On 24 Wrz, 14:41, and(dot)(dot)(dot)(at)dunslane(dot)net (Andrew Dunstan) wrote:
> This is the wrong list to ask this question. This list is about
> development, not usage. Please ask on -general in future.
>
> I presume that where you have "/" you really mean "\".
>
> What version of postgres are you using? If you use a modern version with
> standard_conforming_strings on then you do not need to escape backslashes.
>
> cheers
>
> andrew
>
>
>
>
>
> Thea wrote:
> > Hello folks :)
>
> > I am working on a system that is possible to configure to work with
> > several DBMSes, including PG.
>
> > My problem is that PG behaves differently than other supported DBMSes
> > (MSSQL and MySQL) - when I'm passing a query containing LIKE phrase to
> > it, a double amount of '/' literals is needed to obtain expected
> > result. I do realize that this is caused by a parser 'collapsing'
> > double '/' to a single one.
> > I might not express this clearly, but - as I understand it - in
> > general result is that to find '/' literal in DB, '////' phrase is
> > needed ('////' is turned to '//' by a parser, and that is valid
> > expression for '/' literal in SQL itself).
>
> > The problem is that I cannot really use ESCAPE clause - it would
> > require working on too many files. (there are about 6k files in this
> > project, changing most of them would be not only not feasible, but
> > also risky)
> > The problem is that there is a table with user names. Those can
> > contain '/' literal (if they are domain users for example.) And here I
> > hit the wall. Any search for username with '/' literal fails.
> > I've searched through postgres mailing lists and all feed I could
> > google out, and found some info about problem itself, but I was unable
> > to find a solution for it anywhere.
>
> > Problem was addressed in following locations:
> >http://svr5.postgresql.org/pgsql-general/1999-07/msg00340.php
> >http://svr5.postgresql.org/pgsql-sql/1999-03/msg00144.php
>
> > But those posts are from 1999, and I did not find anything more up-to-
> > date.
> > Has anyone solved this problem?
> > Is there any configuration option in PG allowing to make it behave in
> > a more compliant way?
>
> > I'd be more than happy to see something like Herouth Maoz suggested
> > in
> >http://svr5.postgresql.org/pgsql-general/1999-07/msg00340.php, namely
> > configuration option for PG, but I was unable to find it.
>
> > Sorry if I messed something up... I'm really very confused with this
> > sftuff...
> > I will appreciate any help or explanation, if I missed something
> > important.
>
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: if posting/reading through Usenet, please send an appropriate
> >        subscribe-nomail command to majord(dot)(dot)(dot)(at)postgresql(dot)org so that your
> >        message can get through to the mailing list cleanly
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster- Ukryj cytowany tekst -
>
> - Poka  cytowany tekst -



In response to

pgsql-hackers by date

Next:From: Dave PageDate: 2007-09-24 13:18:38
Subject: Re: CREATE DATABASE cannot be executed from a function or multi-command string
Previous:From: Martin PihlakDate: 2007-09-24 13:10:32
Subject: Re: stored procedure stats in collector

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group