Re: Backslash as ordinary char vs. not; set via a connection/session

Ken Johanson wrote:
> Stefan Kaltenbrunner wrote:
>
>>
>> postgresql can do that in an even more powerful way - but people tend to
>> not notice much of it in your case that would be:
>>
>> ALTER ROLE foo SET standard_conforming_strings='off'
>>
>> or even:
>>
>> ALTER DATABASE bar SET standard_conforming_strings='off'
>>
>> you can do that for nearly all GUCs (like
>> logging,client_encoding,search_path,....)
>>
>>
>> Stefan
>
> Stefan and Alvaro,
>
> Thank you!!! Yes, that is the feature I'd like... and yes, setting it on
> a per role or per database level is something I personally would prefer
> over the connection level. But, is there also a way to set it on the
> connection? Just because, one can imagine scenarios where two APIs share
> the same role & database, but one API forces backslashes 'on' during its
> statement-prepare.... just playing devil's advocate :-)

foo=# create table backslash(baz text);
CREATE TABLE
foo=# set standard_conforming_strings to on;
SET
foo=# insert into backslash values ('\\');
INSERT 0 1
foo=# set standard_conforming_strings to off;
SET
foo=# insert into backslash values ('\\');
WARNING:  nonstandard use of \\ in a string literal
LINE 1: insert into backslash values ('\\');
                                      ^
HINT:  Use the escape string syntax for backslashes, e.g., E'\\'.
INSERT 0 1
foo=# select * from backslash;
 baz
-----
 \\
 \
(2 rows)


like that ? :-)


>
> So is this 'standard_conforming_strings' variable already set-able in a
> recent build, at the role or db level? Or will that need to wait for 8.2?

it's already in -HEAD and will therefor be in 8.2 when that gets released.


Stefan