Re: Document if width_bucket's low and high are inclusive/exclusive
Dean Rasheed <dean.a.rasheed@gmail.com>
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Treat <rob@xzilla.net>,
Ben Peachey Higdon <bpeacheyhigdon@gmail.com>, pgsql-docs@lists.postgresql.org
Date: 2025-06-21T20:26:13Z
Lists: 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
Commits
-
Doc: improve documentation about width_bucket().
- ea06263c4aa5 18.0 landed
- ccfe3dbaa439 15.14 landed
- 9bd588f87de8 14.19 landed
- 9575e540f666 17.6 landed
- 7a93bd5986e4 16.10 landed
- 34a6c679ae35 13.22 landed