Re: Timestamp weirdness

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.

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.

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