Re: daterange() is ignoring 3rd boundaries argument
От | Tom Lane |
---|---|
Тема | Re: daterange() is ignoring 3rd boundaries argument |
Дата | |
Msg-id | 778131.1669682544@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | daterange() is ignoring 3rd boundaries argument (Robert KOFLER <rk@marksim.org>) |
Список | pgsql-bugs |
Robert KOFLER <rk@marksim.org> writes: > select daterange('2022-11-01'::date, '2023-01-31'::date, '()') > returns > [2022-11-02,2023-01-31) which is deafult of [) > instead of > (2022-11-02,2023-01-31) It's not "ignoring" the endpoint argument, because you get different results from regression=# select daterange('2022-11-01'::date, '2023-01-31'::date, '()'); daterange ------------------------- [2022-11-02,2023-01-31) (1 row) regression=# select daterange('2022-11-01'::date, '2023-01-31'::date, '[)'); daterange ------------------------- [2022-11-01,2023-01-31) (1 row) regression=# select daterange('2022-11-01'::date, '2023-01-31'::date, '[]'); daterange ------------------------- [2022-11-01,2023-02-01) (1 row) As explained somewhere in the fine manual (though not in the exact spot you're reading), for ranges over discrete types such as dates, we prefer to normalize to the '[)' endpoint conventions. That's not possible for continuous types such as floats or timestamps, so in those cases we leave the endpoint specs alone. If that really annoys you, you can make your own range type over dates that lacks a "canonical" function. But it's not a bug; it's operating as intended. regards, tom lane
В списке pgsql-bugs по дате отправления: