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

From Dean Rasheed
Subject Re: Document if width_bucket's low and high are inclusive/exclusive
Date
Msg-id CAEZATCXxqt=kYeQpy0hpv9H=Tboa0GW3yj-x856UE-O=w0Kr9w@mail.gmail.com
Whole thread Raw
In response to Re: Document if width_bucket's low and high are inclusive/exclusive  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Document if width_bucket's low and high are inclusive/exclusive
List pgsql-docs
On Sat, 21 Jun 2025 at 18:09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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.)
>

Yes, I think that's a good idea (for v19 I would have thought).
Allowing the operand to be NaN definitely seems preferable to throwing
an error, since the operand might well come from data in a table
containing NaNs.

Regards,
Dean



pgsql-docs by date:

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