Re: daterange() is ignoring 3rd boundaries argument

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

In response to

Browse pgsql-bugs by date

  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