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

Re: BUG #4027: backslash escaping not disabled in plpgsql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jonathan Guthrie" <jguthrie(at)brokersys(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4027: backslash escaping not disabled in plpgsql
Date: 2008-03-12 01:01:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
"Jonathan Guthrie" <jguthrie(at)brokersys(dot)com> writes:
> I have set the standard_conforming_strings to "on" in my settings ...
> However, when I attempt to define this function:

> create function foo (out r refcursor) as $bar$
> begin
>  open r for
>    select * from user_data
>    where name_first like name escape '\';
> end; $bar$ language plpgsql;

plpgsql does not consider standard_conforming_strings --- it still uses
backslash escaping in its function bodies regardless.  Since the
language itself is not standardized, I see no particular reason that
standard_conforming_strings should govern it.  I believe the reason for
not changing it was that it seemed too likely to break existing
functions, with potentially nasty consequences if they chanced to be
security definers.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: longlongDate: 2008-03-12 01:43:33
Subject: Fwd: COPY issue(gsoc project)
Previous:From: Bruce MomjianDate: 2008-03-12 00:23:25
Subject: Re: Reducing Transaction Start/End Contention

pgsql-bugs by date

Next:From: Alex HunsakerDate: 2008-03-12 04:34:56
Subject: 8.3.0 backend segfaults
Previous:From: Bruce MomjianDate: 2008-03-11 23:31:27
Subject: Re: [BUGS] psql \COPY accepts multiple NULL AS

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