Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql
Date
Msg-id 3440.1239303406@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Unless I'm missing something, plpgsql *already* effectively recognizes
> and respects the standard_conforming_strings GUC *except* as the last
> character of a conforming string literal within the procedure body,
> and then not always. Am I missing something here?

Yes --- 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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql
Next
From: "Kevin Grittner"
Date:
Subject: Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql