On Thu, Apr 9, 2009 at 11:16 AM, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
