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: 9798.1205283692@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-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

Responses

Browse pgsql-bugs by date

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

Browse pgsql-hackers by date

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