From: Tom Lane <tgl@sss.pgh.pa.us>
To: Arthur Zakirov <a.zakirov@postgrespro.ru>
cc: amul sul <sulamul@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>,
        Robert Haas <robertmhaas@gmail.com>,
        "David G. Johnston" <david.g.johnston@gmail.com>,
        Alex Ignatov <a.ignatov@postgrespro.ru>,
        Bruce Momjian <bruce@momjian.us>, amul sul <sul_amul@yahoo.co.in>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Bug in to_timestamp().
In-reply-to: <20171119144734.GA12415@arthur.localdomain>
References: 
 <CA+TgmoaFQZeqmAo3CdivNu70coB=9eM5OroKYtNcTuMaC1kuUQ@mail.gmail.com>
 <32684.1466704957@sss.pgh.pa.us>
 <734e50cd-c563-4afd-d1c8-80f244b3265e@postgrespro.ru>
 <CAFj8pRDGxe=cdcZ7pur=2WeW9O3MQCZTBEAOJfQ7OLQJaYXDvw@mail.gmail.com>
 <b2a39359-3282-b402-f4a3-057aae500ee7@postgrespro.ru>
 <29142.1475097531@sss.pgh.pa.us>
 <CAKNkYny-0YJZzz=a9E==UBuiEoMA!FV=n6tik7oLbDVtahiW7tA@mail.gmail.com>
 <8744.1478284597@sss.pgh.pa.us>
 <CAKNkYnxCqwC+aXZFXent27SU5=nonR6JPxJDxfnf9YiXW71PKA@mail.gmail.com>
 <29637.1511045306@sss.pgh.pa.us> <20171119144734.GA12415@arthur.localdomain>
Comments: In-reply-to Arthur Zakirov <a.zakirov@postgrespro.ru>
	message dated "Sun, 19 Nov 2017 17:47:35 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9090.1511112399.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 19 Nov 2017 12:26:39 -0500
Message-ID: <9091.1511112399@sss.pgh.pa.us>
Precedence: bulk

Arthur Zakirov <a.zakirov@postgrespro.ru> writes:
> On Sat, Nov 18, 2017 at 05:48:26PM -0500, Tom Lane wrote:
>> ... I see from your regression test additions that
>> you want to make some of these throw an error, and I think that any suc=
h
>> proposal is dead in the water.  Nobody is going to consider it an
>> improvement if it both breaks working PG apps and disagrees with Oracle=
.

> Only queries with FX field throw an error.

Ah, I see --- I'd missed that FX was relevant to this.  Yeah, maybe
it'd be okay to tighten up in that case, since that's making it act more
like Oracle, which seems to be generally agreed to be a good thing.

I don't much like the error message that you've got:

+SELECT to_timestamp('97/Feb/16', 'FXYY:Mon:DD');
+ERROR:  unexpected character "/", expected ":"
+DETAIL:  The given value did not match any of the allowed values for this=
 field.

The DETAIL message seems to have been copied-and-pasted into a context
where it's not terribly accurate.  I'd consider replacing it with
something along the lines of "HINT: In FX mode, punctuation in the input
string must exactly match the format string."  This way the report will
contain a pretty clear statement of the new rule that was broken.  (BTW,
it's a hint not a detail because it might be guessing wrong as to what
the real problem is.)

			regards, tom lane