Re: [HACKERS] Bug in to_timestamp().

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Bug in to_timestamp().
Дата
Msg-id 29637.1511045306@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Bug in to_timestamp().  (Artur Zakirov <a.zakirov@postgrespro.ru>)
Ответы Re: [HACKERS] Bug in to_timestamp().
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: spgist rangetypes compiler warning (gcc 7.2.0)
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted