Обсуждение: Bad cast priority for DATE?

Folks,

I was noticing that, where we have a function which has two versions,
timestamp and timestamptz (for example, date_trunc()), if I use a DATE
timestamptz is the default cast.  Shouldn't timestamp without time zone
be the default?  Is this something we can fix without an overhaul of the
type casting system?


--                                  -- Josh Berkus                                    PostgreSQL Experts Inc.
                        http://www.pgexperts.com
 

Josh Berkus <josh@agliodbs.com> writes:
> I was noticing that, where we have a function which has two versions,
> timestamp and timestamptz (for example, date_trunc()), if I use a DATE
> timestamptz is the default cast.  Shouldn't timestamp without time zone
> be the default?  Is this something we can fix without an overhaul of the
> type casting system?

timestamptz is a preferred type, so no you probably can't change that
without breaking a lot of stuff.  It's not immediately clear to me why
that's wrong anyway.
        regards, tom lane

> timestamptz is a preferred type, so no you probably can't change that
> without breaking a lot of stuff.  It's not immediately clear to me why
> that's wrong anyway.

Just that having a value implicitly acquire time zone information it
didn't originally have seems dangerous.  But I can't come up with a
specific example of breakage right now -- at least not one on a single
server.

--                                  -- Josh Berkus                                    PostgreSQL Experts Inc.
                        http://www.pgexperts.com