Re: Timestamp weirdness

On 26-Jul-05, at 1:51 PM, Kevin Grittner wrote:

> Hi Oliver,
>
> You're saying that a timestampz read from the protocol stream on the
> server side is always parsed into a TIMESTAMP WITH TIME ZONE. When it
> is assigned to a TIMESTAMP WITHOUT TIME ZONE, there is a cast. The
> cast
> converts the moment into the local time string for that moment in the
> time zone of the database server. I get that.
>
> My question (not well stated, I'm sure) was whether there is a way to
> know, on the server, at the point of handling the timestampz from the
> protocol stream, that it is going to be assigned to a TIMESTAMP
> WITHOUT
> TIME ZONE and use literal assignment rules (i.e., ignore the time zone
> info) instead of the cast rules. The next question was whether this
> would break existing code.
Sort of.... postgres has automatic casting rules, if you tell it that
it is going to be a timestamptz and
it is being assigned to a timestamp then there is a cast function
which is invoked, and vice versa
>
> It sounds like you're well along on another solution, so this becomes
> acedemic. I'm not sure how you're inferring a type with your
> approach,
> but I guess I was thinking that it might be possible to infer
> alternative types for a timestampz.
He is telling the server that he doesn't know what the type is
(INVALID) and the server is going
to cast it appropriately. Much like you do if you do "insert into foo
values('2005-01-01 03:15:34')

>
> I'm new to PostgreSQL, so I appreciate the patience of those who are
> intimately familiar with the code. It's takes quite a while to scan
> through source code and infer it all. I'm hoping to gain a firm
> enough
> understanding to contribute to the code without too many missteps.
>
> -Kevin
>
>
>
>>>> Oliver Jowett <oliver(at)opencloud(dot)com> 07/26/05 9:20 AM >>>
>>>>
> Kevin Grittner wrote:
>
>
>> I assume that the behavior of the server when receiving a timestampz
>> within the protocol couldn't be changed to match the handling of a
>> literal without breaking significant existing code.
>>
>
> (One more time!)
>
> The parsing of timestamptz is just fine, it's the cast to timestamp
> that
> breaks things.
>
> If we get the server to infer a type for the parameter rather than
> explicitly specifying it as timestamptz, then we can avoid that cast.
> Then things don't break.
>
> -O
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>