On Sun, Aug 28, 2011 at 5:39 AM, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 28 August 2011 00:39, Robert Haas <robertmh...@gmail.com> wrote: >> On Sat, Aug 27, 2011 at 7:43 AM, Dean Rasheed <dean.a.rash...@gmail.com> >> wrote: >>> On 27 August 2011 12:29, Dean Rasheed <dean.a.rash...@gmail.com> wrote: >>>> ... if nothing else it has been a >>>> fun exercise figuring out how the datetime string parsing code works. >>> >>> While looking through the current code, I spotted the following oddity: >>> >>> select timestamp 'yesterday 10:30'; >>> timestamp >>> --------------------- >>> 2011-08-26 10:30:00 >>> >>> which is what you'd expect, however: >>> >>> select timestamp '10:30 yesterday'; >>> timestamp >>> --------------------- >>> 2011-08-26 00:00:00 >>> >>> Similarly "today" and "tomorrow" reset any time fields so far, but >>> ISTM that they should really be preserving the hour, min, sec fields >>> decoded so far. >> >> Sounds right to me. Want to send a patch? > > The attached patch makes "today", "tomorrow" and "yesterday" only set > the year, month and day fields. All the other fields are already > initialised to 0 at the start, and may be set non-zero before or after > encountering these special date values. The result should now be > independent of the order of the fields.
OK, committed. Perhaps it should be back-patched, but since this was only discovered during code-reading and not in the wild, I didn't bother. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
