Tom Lane wrote:
>>emergency.shower@gmail.com wrote:
>>
>>>4) When reading from a TIMESTAMP WITH TIME ZONE field, the driver
>>>should create a Timestamp by interpreting the y, M, d, H, m, s values
>>>as UTC timestamp fields. The Calendar, if given, should be ignored.
> Surely 4 should read "by interpreting the y...s values as a timestamp
> in the zone specified as part of the value", not as necessarily UTC.
Yes, you're right.
> The difficulty with both 2 and 3 is that the driver has no very good way
> of knowing whether it's writing to a timestamp with tz or one without.
> We can know the parameter datatype we send, but if that gets converted
> to the other type within the server, you're going to get burnt.
I'm leaning towards using UNKNOWN as the least-bad option for now, plus
some extension mechanism so you can override it if the type inference
does go wrong. Hopefully that should make the commonly-used cases work
without applications needing to do anything weird.
-O
