Tom Lane <t...@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes:
>> Can't that be managed with this CREATE FUNCTION option?:
>> SET configuration_parameter { TO value | = value | FROM CURRENT }
>
> It can be, the question is whether we're prepared to break
everything
> under the sun until people add that.
Well, surely the 8.3 behavior is not what we want.
(1) The plpgsql parser identifies the boundaries of the string based
on backslash escapes.
(2) The character string literal is interpreted based on the GUC
setting the first time the function is executed (and presumably the
first time executed after the function's invalidated).
(3) Subsequent changes to the GUC don't affect how it's interpreted.
scca=# show standard_conforming_strings ;
standard_conforming_strings
-----------------------------
on
(1 row)
scca=# create or replace function kjgtest() returns text language
plpgsql immutable strict as $$ begin return '\x49'; end; $$;
CREATE FUNCTION
scca=# select * from kjgtest();
kjgtest
---------
\x49
(1 row)
scca=# set standard_conforming_strings = off;
SET
scca=# select * from kjgtest();
kjgtest
---------
\x49
(1 row)
scca=# create or replace function kjgtest() returns text language
plpgsql immutable strict as $$ begin return '\x49'; end; $$;
CREATE FUNCTION
scca=# select * from kjgtest();
kjgtest
---------
I
(1 row)
scca=# set standard_conforming_strings = on;
SET
scca=# select * from kjgtest();
kjgtest
---------
I
(1 row)
scca=# create or replace function kjgtest() returns text language
plpgsql immutable strict as $$ begin return '\x49'; end; $$;
CREATE FUNCTION
scca=# set standard_conforming_strings = off;
SET
scca=# select * from kjgtest();
kjgtest
---------
I
(1 row)
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
