Re: [HACKERS] Bug in to_timestamp().

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: [HACKERS] Bug in to_timestamp().
Дата
Msg-id CAPpHfdu3zSBCCyypWV4tdggfzQ8D8ieU6myETKQEQ7J670b=+Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Bug in to_timestamp().  (amul sul <sulamul@gmail.com>)
Ответы Re: [HACKERS] Bug in to_timestamp().  (amul sul <sulamul@gmail.com>)
Список pgsql-hackers
On Wed, Sep 5, 2018 at 3:10 PM amul sul <sulamul@gmail.com> wrote:
> 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:
> > > 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
isthe only change from a correct result to a failure I'd like to officially put it out there for opinion/vote
gathering.  Mine is 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.

So, if no objections for non-FX mode changes, then I'll extract that
part and commit it separately.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


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

Предыдущее
От: Andrey Lepikhov
Дата:
Сообщение: Re: [WIP] [B-Tree] Retail IndexTuple deletion
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pointless check in RelationBuildPartitionDesc