Re: Bug in to_timestamp().
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Steve Crawford <scrawford@pinpointresearch.com>,
Alex Ignatov <a.ignatov@postgrespro.ru>,
Albe Laurenz <laurenz.albe@wien.gv.at>,
amul sul <sul_amul@yahoo.co.in>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-06-24T21:16:38Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford > <scrawford@pinpointresearch.com> wrote: >> 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? The one thing I know about that is different from Oracle and is not something that most people would consider clearly wrong is the behavior of the FM prefix. We think it's a prefix that modifies only the next format code; they think it's a toggle. If we make that act like Oracle, we will silently break an awful lot of applications, and there will be *no way* to write code that is correct under both interpretations. (And no, I do not want to hear "let's fix it with a GUC".) So I'm afraid we're between a rock and a hard place on that one --- but if we let that stand, the argument that Oracle's to_timestamp should be treated as right by definition loses a lot of air. regards, tom lane
Commits
-
Improve behavior of to_timestamp()/to_date() functions
- cf984672427e 12.0 landed
-
Implement TZH and TZM timestamp format patterns
- 11b623dd0a2c 11.0 cited
-
as attache of this mail is patch (to the main tree) with to_char's
- b866d2e2d794 7.1.1 cited