Обсуждение: 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