Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?
>
> regression=# create function foo() returns int as $$
> regression$# begin
> regression$# raise notice 'foo\'s bar';
> regression$# return 1;
> regression$# end$$ language plpgsql;
> CREATE FUNCTION
> regression=# select foo();
> NOTICE: foo's bar
> foo
> -----
> 1
> (1 row)
>
> In this case the string literal isn't actually ever passed to the
> main SQL engine, so the SQL quoting rules aren't relevant. (I don't
> remember offhand if anything besides RAISE works that way.)
>
> It may be that this isn't a very important case, but to claim that
> it doesn't exist is simply wrong.
OK, I didn't try that. Point taken. It is a bigger mess than I
thought then.
The aspect of 8.3 behavior that concerns me most is that neither the
author of a function, nor anyone using it, can control or predict
which way a string literal with a backslash will be interpreted,
unless the author explicitly specifies the SET
standard_conforming_strings clause in the function declaration. I'm
betting that most people writing and using plpgsql functions don't
know that. Any thoughts about what can or should be done about that?
-Kevin
