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 49DF69C1.EE98.0025.0@wicourts.gov
Whole thread Raw
In response to Re: Re: [BUGS] BUG #4027: backslash escapingnotdisabled inplpgsql  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Re: [BUGS] BUG #4027: backslash escapingnotdisabledinplpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> wrote: 
> Surely what matters is the value of the GUC at the time that you did
> the CREATE FUNCTION, not the value at the time you happen to be
> calling it?
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.
See back here in the thread for some behavior which surprised me:
http://archives.postgresql.org/pgsql-hackers/2009-04/msg00519.php
-Kevin


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Re: [BUGS] BUG #4027: backslash escapingnotdisabled inplpgsql
Next
From: l0rins
Date:
Subject: Re: unable to install tsearch2 on PostgreSQL 8.3.7 successfully