Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bGYUN-00059k-6L for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Jun 2016 21:18:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bGYUM-0002mj-KL for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Jun 2016 21:18:10 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bGYSz-0001GE-El for pgsql-hackers@postgresql.org; Fri, 24 Jun 2016 21:16:45 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bGYSx-0003Pf-8R for pgsql-hackers@postgresql.org; Fri, 24 Jun 2016 21:16:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u5OLGc3s000846; Fri, 24 Jun 2016 17:16:38 -0400 From: Tom Lane To: Robert Haas cc: Steve Crawford , Alex Ignatov , Albe Laurenz , amul sul , PostgreSQL-development Subject: Re: Bug in to_timestamp(). In-reply-to: References: <1873520224.1784572.1465833145330.JavaMail.yahoo.ref@mail.yahoo.com> <1873520224.1784572.1465833145330.JavaMail.yahoo@mail.yahoo.com> <20932.1465834344@sss.pgh.pa.us> <11349.1466429771@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Fri, 24 Jun 2016 16:33:59 -0400" Date: Fri, 24 Jun 2016 17:16:38 -0400 Message-ID: <845.1466802998@sss.pgh.pa.us> X-Pg-Spam-Score: -3.3 (---) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers