Re: [BUGS] extract(epoch from infinity) is not 0 - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: [BUGS] extract(epoch from infinity) is not 0
Date
Msg-id CADxJZo0BXaetTCygQV+U-PCgtLv-ksBKTGiZbMzAJ5TzgUCsBg@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] extract(epoch from infinity) is not 0  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [BUGS] extract(epoch from infinity) is not 0
List pgsql-hackers
On 14 July 2011 06:58, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> I don't find the proposed behavior all that suprising, which the
> original behavior surely is.  I guess the bigger question is whether the
> values that timestamptz_part() returns for other cases (than epoch)
> should also be different from 0 when an 'infinity' timestamp is passed.
> (In other words, why should 0 be the assumed return value here?)
>

Well, for example, how do you go about answering the question "what is
the day-of-month of the infinite timestamp?"  The question is
nonsense; it doesn't have a defined day of month, so I think we should
be returning NULL or throwing an error.  Returning zero is definitely
wrong.  I think throwing an error is the better way to go, as the user
probably didn't intend to ask an incoherent question.

It makes sense to special-case 'epoch' because it effectively converts
the operation into interval math; if we ask "how many seconds from
1970-01-01 00:00 UTC until the infinite timestamp?" the answer is
genuinely "infinite seconds".  So +1 for the proposed change for
epoch, and let's throw an error for the other date fields instead of
returning zero.

Cheers,
BJ


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Tweaking the planner's heuristics for small/empty tables
Next
From: Josh Berkus
Date:
Subject: Re: [BUGS] extract(epoch from infinity) is not 0