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 21:24:35 |
Message-ID: | 2823088.1750541075@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 Sat, 21 Jun 2025 at 18:09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
I started a new thread for that, since it's no longer docs material:
https://www.postgresql.org/message-id/2822872.1750540911%40sss.pgh.pa.us
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2025-06-23 14:40:36 | Re: Fix incorrect UUID index entry in function documentation |
Previous Message | Dean Rasheed | 2025-06-21 20:26:13 | Re: Document if width_bucket's low and high are inclusive/exclusive |