Re: [HACKERS] Bug in to_timestamp().

Поиск
Список
Период
Сортировка
От amul sul
Тема Re: [HACKERS] Bug in to_timestamp().
Дата
Msg-id CAAJ_b975xLGtR5Mr3guPov9xdTtNPE3amE5km+=q22czAUAi+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Bug in to_timestamp().  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: [HACKERS] Bug in to_timestamp().  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Список pgsql-hackers
On Wed, Sep 5, 2018 at 3:05 PM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
>
> On Wed, Sep 5, 2018 at 1:22 AM David G. Johnston
> <david.g.johnston@gmail.com> wrote:
> > On Mon, Sep 3, 2018 at 2:30 PM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
> >>
> >> The current version of patch doesn't really distinguish spaces and
> >> delimiters in format string in non-FX mode.  So, spaces and delimiters
> >> are forming single group.  For me Oracle behavior is ridiculous at
> >> least because it doesn't allow cases when input string exactly matches
> >> format string.
> >>
> >> This one fails:
> >> SELECT to_timestamp('2018- -01 02', 'YYYY- -MM DD') FROM dual
> >
> > Related to below - since this works today it should continue to work.  I was under the wrong impression that we
followedtheir behavior today and were pondering deviating from it because of its ridiculousness. 
>
> Right, that's just incompatibility with Oracle behavior, not with our
> previous behavior.
>
> >> > The couple of regression tests that change do so for the better.  It would be illuminating to set this up as two
patchesthough, one introducing all of the new regression tests against the current code and then a second patch with
thechanged behavior with only the affected tests. 
> >>
> >> OK, here you go.  0001-to_timestamp-regression-test-v17.patch
> >> introduces changes in regression tests and their output for current
> >> master, while 0002-to_timestamp-format-checking-v17.patch contain
> >> changes to to_timestamp itself.
> >>
> >
> > From those results the question is how important is it to force the following breakage on our users (i.e.,
introduceFX exact symbol matching): 
> >
> > SELECT to_timestamp('97/Feb/16', 'FXYY:Mon:DD');
> > -         to_timestamp
> > -------------------------------
> > - Sun Feb 16 00:00:00 1997 PST
> > -(1 row)
> > -
> > +ERROR:  unexpected character "/", expected character ":"
> > +HINT:  In FX mode, punctuation in the input string must exactly match the format string.
> >
> > There seemed to be some implicit approvals of this breakage some 30 emails and 10 months ago but given that this is
theonly change from a correct result to a failure I'd like to officially put it out there for opinion/vote gathering.
Mineis a -1; though keeping the distinction between space and non-alphanumeric characters is expected. 
>
> Do I understand correctly that you're -1 to changes to FX mode, but no
> objection to changes in non-FX mode?
>
Ditto.

Regards,
Amul Sul.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Bug in ginRedoRecompress that causes opaque data on page to be overrun
Следующее
От: Andrey Lepikhov
Дата:
Сообщение: Re: [WIP] [B-Tree] Retail IndexTuple deletion