Re: Document if width_bucket's low and high are inclusive/exclusive
От | Tom Lane |
---|---|
Тема | Re: Document if width_bucket's low and high are inclusive/exclusive |
Дата | |
Msg-id | 2732038.1750525788@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Document if width_bucket's low and high are inclusive/exclusive (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: Document if width_bucket's low and high are inclusive/exclusive
|
Список | 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 по дате отправления: