Re: timestamptz parsing bug?

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: timestamptz parsing bug?
Дата
Msg-id 20120825214509.GD10814@momjian.us
обсуждение исходный текст
Ответ на Re: timestamptz parsing bug?  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Wed, Aug 15, 2012 at 05:29:26PM -0400, Bruce Momjian wrote:
> 
> I assume we want to apply this patch based on discussion that we should
> allow a wider range of date/time formats.

Applied, thanks.

---------------------------------------------------------------------------

> 
> On Mon, Aug 29, 2011 at 06:40:07PM +0100, Dean Rasheed wrote:
> > On 29 August 2011 15:40, Andrew Dunstan <andrew@dunslane.net> wrote:
> > >
> > > Why do we parse this as a correct timestamptz literal:
> > >
> > >    2011-08-29T09:11:14.123 CDT
> > >
> > > but not this:
> > >
> > >    2011-08-29T09:11:14.123 America/Chicago
> > >
> > > Replace the ISO-8601 style T between the date and time parts of the latter
> > > with a space and the parser is happy again.
> > >
> > >
> > > cheers
> > >
> > > andrew
> > >
> > 
> > Funny, I've just recently been looking at this code.
> > 
> > I think that the issue is in the DTK_TIME handling code in DecodeDateTime().
> > 
> > For this input string the "T" is recognised as the start of an ISO
> > time, and the ptype variable is set to DTK_TIME. The next field is a
> > DTK_TIME, however, when it is handled it doesn't reset the ptype
> > variable.
> > 
> > When it gets to the timezone "America/Chicago" at the end, this is
> > handled in the DTK_DATE case, because of the "/". But because ptype is
> > still set, it is expecting this to be an ISO time, so it errors out.
> > 
> > The attached patch seems to fix it. Could probably use a new
> > regression test though.
> > 
> > Regards,
> > Dean
> 
> > diff --git a/src/backend/utils/adt/datetime.c b/src/backend/utils/adt/datetime.c
> > new file mode 100644
> > index 3d320cc..a935d98
> > *** a/src/backend/utils/adt/datetime.c
> > --- b/src/backend/utils/adt/datetime.c
> > *************** DecodeDateTime(char **field, int *ftype,
> > *** 942,947 ****
> > --- 942,957 ----
> >                   break;
> >   
> >               case DTK_TIME:
> > +                 /*
> > +                  * This might be an ISO time following a "t" field.
> > +                  */
> > +                 if (ptype != 0)
> > +                 {
> > +                     /* Sanity check; should not fail this test */
> > +                     if (ptype != DTK_TIME)
> > +                         return DTERR_BAD_FORMAT;
> > +                     ptype = 0;
> > +                 }
> >                   dterr = DecodeTime(field[i], fmask, INTERVAL_FULL_RANGE,
> >                                      &tmask, tm, fsec);
> >                   if (dterr)
> 
> > 
> > -- 
> > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-hackers
> 
> 
> -- 
>   Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>   EnterpriseDB                             http://enterprisedb.com
> 
>   + It's impossible for everything to be true. +
> 
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_stat_replication vs StandbyReplyMessage
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: PATCH: pgbench - random sampling of transaction written into log