Re: Fix some corner cases that cube_in rejects
От | Greg Stark |
---|---|
Тема | Re: Fix some corner cases that cube_in rejects |
Дата | |
Msg-id | CAM-w4HOLEejnJxTYTn=j8XjQJfYoh1Z+k711cfLkPSAi0HzyhQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Fix some corner cases that cube_in rejects (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Fix some corner cases that cube_in rejects
|
Список | pgsql-hackers |
On Mon, Aug 29, 2016 at 7:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > To deal with the infinity/NaN issues, I made cube_in and cube_out rely > on float8in_internal and float8out_internal, as we recently did for the > core geometric types. That causes the response to "1e-700" to be an > out-of-range error rather than silent underflow, which seems to me to > be fine, especially since it removes the platform dependency that's > responsible for needing the separate cube_1.out and cube_3.out files. So what happens to a database that has invalid cubes in it already? Offhand I suspect they mostly become valid since float8in will handle NaN and the like. Incidentally, I so wish this module were named "vector" instead of cube. I don't think I was confused by it for ages and still find it confuses me for a few moments before I remember what it does. -- greg
В списке pgsql-hackers по дате отправления: