| From: | Ken Johanson <pg-user(at)kensystem(dot)com> | 
|---|---|
| To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> | 
| Cc: | ken(at)kensystem(dot)com, pgsql-general(at)postgresql(dot)org | 
| Subject: | Re: Backslash as ordinary char vs. not; set via a connection/session | 
| Date: | 2006-07-27 20:51:48 | 
| Message-ID: | 44C92764.4060400@kensystem.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
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 :-)
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?
Thanks again!!!!!!
ken
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruno Wolff III | 2006-07-27 20:59:01 | Re: Can't start PostgreSQL | 
| Previous Message | Stefan Kaltenbrunner | 2006-07-27 20:37:49 | Re: Backslash as ordinary char vs. not; set via a connection/session |