Re: Inputting relative datetimes

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Inputting relative datetimes
Дата
Msg-id CA+TgmobcvtmdQUU05OrgGqVzFDE9ppmE7UeCkdgiuz94pkhrAA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Inputting relative datetimes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Inputting relative datetimes  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Inputting relative datetimes
Следующее
От: Robert Haas
Дата:
Сообщение: Re: dropdb and dropuser: IF EXISTS