Re: BUG #4027: backslash escaping not disabled in plpgsql - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #4027: backslash escaping not disabled in plpgsql
Date
Msg-id 9798.1205283692@sss.pgh.pa.us
Whole thread Raw
In response to BUG #4027: backslash escaping not disabled in plpgsql  ("Jonathan Guthrie" <jguthrie@brokersys.com>)
Responses Re: BUG #4027: backslash escaping not disabled in plpgsql  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-bugs
"Jonathan Guthrie" <jguthrie@brokersys.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

pgsql-bugs by date:

Previous
From: "Jonathan Guthrie"
Date:
Subject: BUG #4027: backslash escaping not disabled in plpgsql
Next
From: "Alex Hunsaker"
Date:
Subject: 8.3.0 backend segfaults