Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);
Date
Msg-id 473944.1715176550@sss.pgh.pa.us
Whole thread Raw
In response to BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);  ("Wetmore, Matthew (CTR)" <Matthew.Wetmore@evernorth.com>)
List pgsql-bugs
"Wetmore, Matthew  (CTR)" <Matthew.Wetmore@evernorth.com> writes:
> Devils advocating here, feel free to ignore.
> Is there a real need for a negative month?  Sounds like high level this could be disastrous if I screw up the syntax.
(Ah,memories of DD) 

What are you objecting to the "need for"?  That intervals can store
negative months at all?  I think that ship sailed a couple decades
ago.  It's hard to use interval as the output of, say,
timestamp minus timestamp if it refuses to allow negative values.

The next fallback position perhaps could be that extract(quarter ...)
could throw error for negative input, but that seems like mostly a
foot-gun.  We've striven elsewhere to not have it throw error, even
if there's not any very sane choice to make.  For instance, these
are pre-existing behaviors:

regression=# select extract(quarter from interval 'infinity');
 extract
---------

(1 row)

regression=# select extract(quarter from interval '-infinity');
 extract
---------

(1 row)

Maybe there's a case for returning null for "quarter" for any negative
months value, but that seems inconsistent with other behaviors of
extract().  The pattern I see for finite values is that negating
the input interval negates each output of extract().

            regards, tom lane



pgsql-bugs by date:

Previous
From: Chris Travers
Date:
Subject: pg_rewind fails on Windows where tablespaces are used
Next
From: Tom Lane
Date:
Subject: Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);