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

From Tom Lane
Subject Re: [HACKERS] Bug in to_timestamp().
Date
Msg-id 29637.1511045306@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug in to_timestamp().  (Artur Zakirov <a.zakirov@postgrespro.ru>)
Responses Re: [HACKERS] Bug in to_timestamp().  (Arthur Zakirov <a.zakirov@postgrespro.ru>)
List pgsql-hackers
Artur Zakirov <a.zakirov@postgrespro.ru> writes:
> [ 0001-to-timestamp-format-checking-v7.patch ]

This patch needs a rebase over the formatting.c fixes that have gone
in over the last couple of days.

Looking at the rejects, I notice that in your changes to parse_format(),
you seem to be making it rely even more heavily on remembering state about
the previous input.  I recommend against that --- it was broken before,
and it's a pretty fragile approach.  Backslashes are not that hard to
deal with in-line.

The larger picture though is that I'm not real sure that this patch is
going in the direction we want.  All of these cases work in both our
code and Oracle:

select to_timestamp('97/Feb/16', 'YY:Mon:DD')
select to_timestamp('97/Feb/16', 'YY Mon DD')
select to_timestamp('97 Feb 16', 'YY/Mon/DD')

(Well, Oracle thinks these mean 2097 where we think 1997, but the point is
you don't get an error.)  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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: spgist rangetypes compiler warning (gcc 7.2.0)
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted