Re: Document if width_bucket's low and high are inclusive/exclusive - Mailing list pgsql-docs

From Tom Lane
Subject Re: Document if width_bucket's low and high are inclusive/exclusive
Date
Msg-id 2732038.1750525788@sss.pgh.pa.us
Whole thread Raw
In response to Re: Document if width_bucket's low and high are inclusive/exclusive  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Document if width_bucket's low and high are inclusive/exclusive
List pgsql-docs
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> On Fri, 20 Jun 2025 at 22:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So concretely, how about the attached?

> LGTM (though I'm not sure it really needs the word "therefore" in the
> first hunk).

OK, done that way.

> There are also a couple of code comments that need fixing --

Good points, also done.

While looking at those comments, I also noted that there is a
strange inconsistency between width_bucket_array and
width_bucket_float8/width_bucket_numeric.  Namely, the latter
two reject an "operand" that is NaN, while width_bucket_array
goes out of its way to accept it and treat it in our usual
fashion as sorting higher than all non-NaNs.

Clearly these functions must reject NaN histogram bounds, for
the same reason they reject infinite bounds.  But I don't see
any reason why they couldn't treat a NaN operand as valid.
Should we change them?  (I imagine this'd be a HEAD-only
change, and probably v19 material at this point.)

            regards, tom lane



pgsql-docs by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Document if width_bucket's low and high are inclusive/exclusive
Next
From: Dean Rasheed
Date:
Subject: Re: Document if width_bucket's low and high are inclusive/exclusive