Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql
От | Tom Lane |
---|---|
Тема | Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql |
Дата | |
Msg-id | 3440.1239303406@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Re: [BUGS] BUG #4027: backslash escaping
notdisabled inplpgsql
|
Список | 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 по дате отправления: