Re: Inputting relative datetimes - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Inputting relative datetimes
Date
Msg-id CA+TgmobcvtmdQUU05OrgGqVzFDE9ppmE7UeCkdgiuz94pkhrAA@mail.gmail.com
Whole thread Raw
In response to Re: Inputting relative datetimes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Inputting relative datetimes
List pgsql-hackers
On Tue, Aug 30, 2011 at 11:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Aug 28, 2011 at 5:39 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>>> 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,
>
> No, I don't think so.  This is an incompatible behavioral change with a
> small-but-not-zero probability of breaking existing applications.

Well, I'm fine with not back-patching it, but think the existing
behavior is flat wrong.  Having '04:00:00 yesterday' return midnight
yesterday is pretty well unjustifiable.  An error would be reasonable,
and DWIM is reasonable, but anything else is the wrong answer.  How
much worse would it have to be to qualify as a bug?  What if we didn't
the hour, minute, and second at all, and returned a value based on
whatever garbage was left over in the relevant memory location?  What
if we returned 40000 BC?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Inputting relative datetimes
Next
From: Robert Haas
Date:
Subject: Re: dropdb and dropuser: IF EXISTS