Re: Backslash as ordinary char vs. not; set via a connection/session
От | Ken Johanson |
---|---|
Тема | Re: Backslash as ordinary char vs. not; set via a connection/session |
Дата | |
Msg-id | 44C92764.4060400@kensystem.com обсуждение исходный текст |
Ответ на | Re: Backslash as ordinary char vs. not; set via a connection/session (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
Ответы |
Re: Backslash as ordinary char vs. not; set via a connection/session
|
Список | 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
В списке pgsql-general по дате отправления: