From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | rk(at)marksim(dot)org |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: daterange() is ignoring 3rd boundaries argument |
Date: | 2022-11-29 00:42:24 |
Message-ID: | 778131.1669682544@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Robert KOFLER <rk(at)marksim(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2022-11-29 02:19:00 | Re: BUG #17700: An assert failed in prepjointree.c |
Previous Message | David G. Johnston | 2022-11-29 00:35:32 | Re: daterange() is ignoring 3rd boundaries argument |