From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Steve Crawford <scrawford(at)pinpointresearch(dot)com>, Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, amul sul <sul_amul(at)yahoo(dot)co(dot)in>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug in to_timestamp(). |
Date: | 2016-06-24 21:16:38 |
Message-ID: | 845.1466802998@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
> <scrawford(at)pinpointresearch(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-06-24 21:18:20 | Re: tuplesort.c's copytup_index() is dead code |
Previous Message | Peter Geoghegan | 2016-06-24 21:09:58 | Re: tuplesort.c's copytup_index() is dead code |