tgl@sss.pgh.pa.us (Tom Lane) writes:
> Chris Browne <cbbrowne@acm.org> writes:
>> Unfortunately (perhaps) standards_conforming_strings does not appear
>> to be exported, so I'm not sure how to do this otherwise.
>
> Perhaps your problem is one of spelling? It's
> "standard_conforming_strings", and it's certainly a global variable.
>
> You still haven't explained why you need this, though. There are
> no datatype output functions that examine this variable.
Apologies. I was reading too much into the problem report.
After some discussion on IRC, I think we've "simplified" things back
to what the problem is.
Our logtrigger() function is already applying a "non-SCS" policy to
quote backslashes. No need to declare anything there, as had been the
case with a recent DateStyle issue.
With DateStyle, we had to control the style in two places:1. In logtrigger(), when PostgreSQL is asked to generate the
string version of a datestamp. We do so by temporarily setting DateStyle.2. When loading data, we need to make
surethe connection uses a consistent DateStyle. We do so by setting the GUC variable using SET.
I was under the misapprehension that we needed something akin to that
step 1; apparently we only need worry about step 2. To which Peter's
suggestion is entirely sufficient.
Sorry about the confusion.
--
let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/internet.html
"Who is General Failure and why is he reading my hard disk?"
-- <leitner@inf.fu-berlin.de>, Felix von Leitner
