Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql
От | Kevin Grittner |
---|---|
Тема | Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql |
Дата | |
Msg-id | 49DDF86C.EE98.0025.0@wicourts.gov обсуждение исходный текст |
Ответ на | Re: Re: [BUGS] BUG #4027: backslash escaping not disabled inplpgsql ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql
|
Список | pgsql-hackers |
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > Well, surely the 8.3 behavior is not what we want. 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? scca=# set standard_conforming_strings = on; SET scca=# create or replace function kjgtest() returns text language plpgsql immutable as 'begin return \'\x49\'; end;'; Expanded display is on. Invalid command \';. Try \? for help. scca=# \x Expanded display is off. scca-# create or replace function kjgtest() returns text language plpgsql immutable as $$ begin return '\x49\'; end; $$; ERROR: syntax error at or near "create" LINE 2: create or replace function kjgtest() returns text language p... ^ 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) scca=# set standard_conforming_strings = off; SET scca=# create or replace function kjgtest() returns text language plpgsql immutable as 'begin return \'\x49\'; end;'; CREATE FUNCTION scca=# select kjgtest();kjgtest ---------I (1 row) scca=# create or replace function kjgtest() returns text language plpgsql immutable as $$ begin return '\x49\'; end; $$; ERROR: unterminated string CONTEXT: compile of PL/pgSQL function "kjgtest" near line 1 scca=# create or replace function kjgtest() returns text language plpgsql immutable as $$ begin return '\x49\\'; end; $$; CREATE FUNCTION scca=# select kjgtest();kjgtest ---------I\ (1 row) Given this behavior, how much could be working for standard_conforming_strings = on which would break with more complete support? Maybe this particular GUC should default to an implied SET standard_conforming_strings FROM CURRENT and the plpgsql parser should use it? Can anyone show a working case that would break with that? -Kevin
В списке pgsql-hackers по дате отправления: