Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql

Tom Lane <tgl@sss.pgh.pa.us> wrote: 
> I think you are confusing parsing of the string literal that
> is the argument of CREATE FUNCTION with the parsing that the plpgsql
> interpreter does on the function body once it gets it.  In
> particular, this example:
> 
> create or replace function kjgtest() returns text language
> plpgsql immutable as $$ begin return 'foo\'; end; $$;
> 
> fails regardless of the standard_conforming_strings setting, because
> the plpgsql interpreter considers the backslash to escape the quote
> regardless.
 
Oh, I'm not confused about that at all.  I'm arguing that it's a bad
idea.  I agree with the OP that this is a bug.  Did you look at my
other examples of behavior?  In particular:
 
scca=# create or replace function kjgtest() returns text language
plpgsql immutable as $$ begin return '\x49\\'; end; $$;
CREATE FUNCTION
scca=# select kjgtest();
 kjgtest
---------
 \x49\\
(1 row)
 
Can you show one case where having plgpsql parse the function body
based on the standard_conforming_strings GUC would break *anything*
that now works?  That's an allegation which I haven't been able to
confirm, so I'm wondering about the basis.
 
-Kevin