Josh Berkus <j...@agliodbs.com> writes:
>> The remote end has entirely misinterpreted the day vs month fields.
>> Now, to hit this you need to be using a datestyle which will print
>> in an ambiguous format, so the "ISO" and "Postgres" styles are
>> not vulnerable; but "German" and "SQL" are.
> Is the "timezone" GUC a problem, also, for this? Seems like that could
> be much worse ...
I'm not sure why you think being off by an hour is "much worse" than
being off by nine months ;-). But anyway, timezone seems to be mostly a
cosmetic issue, since timestamptz values will always get printed with an
explicit zone value. I think you could possibly burn yourself if a
foreign table were declared as being type timestamp when the underlying
column is really timestamptz ... but that kind of misconfiguration would
probably create a lot of misbehaviors above and beyond this one.
Having said that, I'd still be inclined to try to set the remote's
timezone GUC just so that error messages coming back from the remote
don't reflect a randomly different timezone, which was the basic issue
in the buildfarm failures we saw yesterday. OTOH, there is no guarantee
at all that the remote has the same timezone database we do, so it may
not know the zone or may think it has different DST rules than we think;
so it's not clear how far we can get with that. Maybe we should just
set the remote session's timezone to GMT always.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
