Kevin Grittner <kgri...@ymail.com> writes:
> On Monday, November 9, 2015 9:37 AM, Robert Haas <robertmh...@gmail.com>
> wrote:
>> That doesn't seem like enough consensus to commit this patch, which
>> would change everything to +/-infinity. That particular choice
>> wouldn't bother me much, but it sounds like other people aren't sold.
>> I think we need to try to hash that out a little more rather than
>> rushing into a backward-incompatible change.
> I agree that none of this should be back-patched.
Definitely.
> I agree that a timestamp[tz] of infinity should yield infinity for
> epoch.
I think everybody is sold on that much.
> My first choice for other things would be NaN, but throwing an
> error instead would be OK.
Since the function hasn't thrown error for such cases in the past, making
it do so now would likely break applications. More than once, we've
had to modify functions to avoid throwing errors so that you don't get
incidental errors when blindly applying a function to all entries in a
column. I think going in the opposite direction would elicit protests.
I could see using NaN except for one thing: it'd mean injecting a rather
fundamental dependence on IEEE math into a basic function definition. You
can be just about 100% certain that if the SQL committee ever addresses
this case, it won't be with NaN.
What about returning NULL for the ill-defined cases? That seems to
comport with SQL's notion of NULL as "unknown/undefined".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
