To me, 2016-02-30 is an invalid date that should generate an error.
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.
Agreed, mostly, but ... how far are we prepared to go on that?
We don't at all. Our goal has never been Oracle compatibility. Yes, we have "made allowances" but we aren't in a position that requires that anymore.
Let's just do it right.
Sincerely,
JD
/me speaking as someone who handles many, many migrations, none of which have ever said, "do we have Oracle compatibility available".
Tongue (partlyish) in cheek:
Developer: I need a database to support my project. Based on my research this PostgreSQL thing is awesome so we will use it.
PostgreSQL: Welcome to our community!
Developer: I need to convert a string to a timestamp. This to_timestamp() function I tried does not operate as I expect based on the documentation.
PostgreSQL: Ah, yes, grasshopper. You are young and do not understand the Things That Must Not Be Documented . In time you will grow a gray ponytail and/or white beard and learn the history and ways of every database that came before. Only then will you come to understand how The Functions *truly* behave.
Developer: Are you #@%!$ kidding me?
I will allow that there may be selected cases where a good argument could be made for intentionally overly permissive behavior in the pursuit of compatibility. But in those cases the documentation should specify clearly and in detail the deviant behavior and reason for its existence.
As one who selected PostgreSQL from the start, I am more interested in the functions working correctly.