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