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

From Arthur Zakirov
Subject Re: [HACKERS] Bug in to_timestamp().
Date
Msg-id 20180302093328.GA18933@zakirov.localdomain
Whole thread Raw
In response to Re: [HACKERS] Bug in to_timestamp().  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: [HACKERS] Bug in to_timestamp().  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
On Fri, Mar 02, 2018 at 12:58:57AM +0100, Dmitry Dolgov wrote:
> > On 18 February 2018 at 18:49, Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> > > On 17 February 2018 at 10:02, Arthur Zakirov <a.zakirov@postgrespro.ru>
> wrote:
> > > ...
> > > I think it could be fixed by another patch. But I'm not sure that it
> > > will be accepted as well as this patch :).
> >
> > Why do you think there should be another patch for it?
> 
> Just to make myself clear. I think it's fair enough to mark this patch as
> ready
> for committer - the implementation is neat and sufficient as for me, and it
> provides a visible improvement for user experience. The question above is
> probably the only thing that prevents me from proposing this.

The fix you proposed isn't related with the initial report [1] by Amul
Sul, IMHO. The patch tries to fix that behaviour and additionally tries
to be more smart in handling and matching separator characters within
input and format strings. And unfortunately, it partly breaks backward
compatibility.

Your propose could break backward compatibility too, I think. And in
different manner than the patch I think. And that's why it needs another
patch I think and needs an additional decision about breaking backward
compatibility. All this is IMHO.


1 - https://www.postgresql.org/message-id/1873520224.1784572.1465833145330.JavaMail.yahoo%40mail.yahoo.com

-- 
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company


pgsql-hackers by date:

Previous
From: Ildus Kurbangaliev
Date:
Subject: Re: 2018-03 Commitfest Summary (Andres #3)
Next
From: Amit Kapila
Date:
Subject: Re: zheap: a new storage format for PostgreSQL