On 25/06/16 08:33, Robert Haas wrote:
On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
My observation has been that the PostgreSQL development group aims for
correctness and the elimination of surprising results. This was part of the
reason to eliminate a number of automatic casts to dates in earlier
To me, 2016-02-30 is an invalid date that should generate an error.
Automatically and silently changing it to be 2016-03-01 strikes me as a
behavior I'd expect from a certain other open-source database, not
I don't particularly disagree with that, but on the other hand, as
mentioned earlier, to_timestamp() is here for Oracle compatibility,
and if it doesn't do what Oracle's function does, then (1) it's not
useful for people migrating from Oracle and (2) we're making up the
behavior out of whole cloth. I think things that we invent ourselves
should reject stuff like this, but in a compatibility function we
might want to, say, have compatibility.
How about a to_timestamp_strict(), in addition?
Its very existence will help people (who bother to read the
documentation) to look more closely at the differences between the
definitions, and allow them to choose the most appropriate for their use
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: