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
