From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Robert Treat <rob(at)xzilla(dot)net>, Ben Peachey Higdon <bpeacheyhigdon(at)gmail(dot)com>, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Document if width_bucket's low and high are inclusive/exclusive |
Date: | 2025-06-21 17:09:48 |
Message-ID: | 2732038.1750525788@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Fri, 20 Jun 2025 at 22:19, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2025-06-21 20:26:13 | Re: Document if width_bucket's low and high are inclusive/exclusive |
Previous Message | Dean Rasheed | 2025-06-21 08:01:32 | Re: Document if width_bucket's low and high are inclusive/exclusive |