Re: Re: [BUGS] BUG #4027: backslash escapingnotdisabledinplpgsql - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Re: [BUGS] BUG #4027: backslash escapingnotdisabledinplpgsql
Date
Msg-id 49E346E9.EE98.0025.0@wicourts.gov
Whole thread Raw
In response to Re: Re: [BUGS] BUG #4027: backslash escapingnotdisabledinplpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote: 
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> a change to CREATE FUNCTION such that there is an implied SET
>> standard_compliant_strings FROM CURRENT
Hopefully obvious, I meant standard_conforming_strings.
> it seems like a really bad idea.
Then perhaps a note in the PL/pgSQL docs about the importance of
specifying that clause if the function contains any character string
literals which include a backslash?  Such a note should probably point
out that without this clause, the runtime value of any such literal
will be dependent on the value of standard_conforming_strings when the
plan is generated.
I think that many will find that behavior surprising; so if it's not
feasible to change it, we should at least document it.
-Kevin


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: add columns created and altered to pg_proc and pg_class
Next
From: Robert Haas
Date:
Subject: join ordering