From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix some corner cases that cube_in rejects |
Date: | 2016-08-29 19:44:56 |
Message-ID: | CAM-w4HOLEejnJxTYTn=j8XjQJfYoh1Z+k711cfLkPSAi0HzyhQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 29, 2016 at 7:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-08-29 19:54:18 | Re: Fix some corner cases that cube_in rejects |
Previous Message | Martín Marqués | 2016-08-29 19:42:43 | Re: pg_dump with tables created in schemas created by extensions |