Re: Re: [BUGS] BUG #4027: backslash escapingnotdisabledinplpgsql

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Well, that's a change I'm arguing for.  That would require both the
> plpgsql parser change Tom is talking about, and a change to CREATE
> FUNCTION such that there is an implied SET standard_compliant_strings
> FROM CURRENT -- which is something I've suggested a couple times;
> there's been no explicit response to that.

If you want one: it seems like a really bad idea.  Aside from the sheer
ugliness of special-casing one particular GUC, it would break existing
pg_dump files, since pg_dump has no idea that its setting of
standard_conforming_strings might influence the behavior of functions
it defines.

I don't actually see that standard_conforming_strings is worse than
search_path or half a dozen other settings that will influence the
semantics of SQL queries.  If anything it's less bad than those since
it's less likely to break things silently.  The whole topic just
illustrates that "invent a GUC" is not a pain-free solution to handling
definitional conflicts.
        regards, tom lane