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