Tom Lane <t...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
