"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes:
> Tom Lane <t...@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.
> 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?
I ignored all the ones that used non-dollar-quote syntax for the overall
function body, since they are just confusing the issue.
> 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
