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 222870.1708458150@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);  (jian he <jian.universality@gmail.com>)
Responses Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
jian he <jian.universality@gmail.com> writes:
> On Sun, Feb 18, 2024 at 2:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (Parenthetically, one case that perhaps is surprising is
>> ERROR:  unit "week" not supported for type interval
>> Why not just return the day field divided by 7?)

> seems pretty simple?

Hm, maybe, but does this behave desirably for zero or negative days?

> So in section 9.9.1. EXTRACT, date_part
> we may need to document extract(quarter from interval) case.
> intervals can be negative, which will make the issue more complicated.
> except the "quarter" field , EXTRACT other fields from intervals, the
> output seems sane.

Yeah, I see what you mean: the output for negative month counts is
very bizarre, whereas other fields seem to all produce the negative
of what they'd produce for the absolute value of the interval.
We could either try to fix that or decide that rejecting "quarter"
for intervals is the saner answer.

I went ahead and pushed the docs changes after adding more explicit
descriptions of interval's behavior for the field types where it
seemed important.  If we make any changes to the behavior for
week or quarter fields, ISTM that should be a HEAD-only change.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: error "can only drop stats once" brings down database
Next
From: Tom Lane
Date:
Subject: Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);