Re: Timestamp weirdness

On 24-Jul-05, at 7:41 PM, Oliver Jowett wrote:

> 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.

Seems like this is the only way to go for now. +1 from me.
>
> -O
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>
>

Dave Cramer
davec@postgresintl.com
www.postgresintl.com
ICQ #14675561
jabber davecramer@jabber.org
ph (519 939 0336 )