On Thu, Apr 9, 2009 at 11:16 AM, Bruce Momjian <bruce@momjian.us> wrote:
> Peter Eisentraut wrote:
>> Tom Lane wrote:
>> > 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 think plpgsql should behave either consistently with the rest of PostgreSQL
>> or with Oracle, which it is copied from.
>>
>> > 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.
>>
>> Is this actually true or did we just forget it? :-)
>
> I have added this TODO item:
>
> Consider honoring standard_conforming_strings in PL/pgSQL function
> bodies
>
> * http://archives.postgresql.org/pgsql-bugs/2008-03/msg00102.php
>
> Are we every going to enable standard_conforming_strings by default? If
> not, I will remove the TODO item mentiong this.
> standard_conforming_strings was added in Postgres 8.1, and
> escape_string_warning was enabled in 8.2.
>
> I think the big issue is that having standard_conforming_strings affect
> function behavior introduces the same problems we have had in the past
> of having a GUC affect function behavior.
I think this should wait at least one more release. Based on my
experience, there are probably a LOT of applications out there that
have yet to be updated.
It wouldn't bother me if we never enabled it by default, either. I'm
just -1 on doing it now.
...Robert