Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);
От | Tom Lane |
---|---|
Тема | Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); |
Дата | |
Msg-id | 222870.1708458150@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); (jian he <jian.universality@gmail.com>) |
Ответы |
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);
|
Список | 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 по дате отправления: