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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Brendan Jurd wrote:
>> I agree that there are probably a great many app authors out there who
>> don't realise how very boned they might be if the default GUC gets
>> changed and they haven't prepared their SQL to cope.

> I assume those authors are getting warnings, which is something we don't
> for PL/pgSQL now.

To the extent that the strings are getting passed through to the main
SQL engine, they do get warnings now, and pretty noisy ones:

regression=# create function foo2() returns text as $$
begin
return 'foo\'s bar';
end$$ language plpgsql;
WARNING: nonstandard use of \' in a string literal
LINE 1: SELECT 'foo\'s bar'
^
HINT: Use '' to write quotes in strings, or use the escape string syntax (E'...').
QUERY: SELECT 'foo\'s bar'
CONTEXT: SQL statement in PL/PgSQL function "foo2" near line 2
CREATE FUNCTION
regression=# select foo2();
WARNING: nonstandard use of \' in a string literal
LINE 1: SELECT 'foo\'s bar'
^
HINT: Use '' to write quotes in strings, or use the escape string syntax (E'...').
QUERY: SELECT 'foo\'s bar'
CONTEXT: PL/pgSQL function "foo2" line 2 at RETURN
foo2
-----------
foo's bar
(1 row)

It's the corner cases where plpgsql doesn't pass strings through that
are worrisome. It's possible that RAISE is the only such case ---
anyone want to check?

Actually, what this thread is leading me towards is the idea that almost
nobody really has standard_conforming_strings turned on in production
(except maybe with apps ported from Oracle or someplace else). If they
did, we'd be seeing more complaints about plpgsql not working properly.
So maybe we *could* change plpgsql to honor the GUC without anyone
noticing too much.

regards, tom lane