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

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-general by date

  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