Re: [HACKERS] Bug in to_timestamp(). - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Bug in to_timestamp().
Date
Msg-id 9091.1511112399@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Bug in to_timestamp().  (Arthur Zakirov <a.zakirov@postgrespro.ru>)
Responses Re: [HACKERS] Bug in to_timestamp().  (Arthur Zakirov <a.zakirov@postgrespro.ru>)
List pgsql-hackers
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 such
>> 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


pgsql-hackers by date:

Previous
From: Arthur Zakirov
Date:
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
Next
From: David Fetter
Date:
Subject: Re: percentile value check can be slow