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 по дате отправления:
Следующее
От: Jeff JanesДата:
Сообщение: Re: PATCH: pgbench - random sampling of transaction written into log