Re: Fix some corner cases that cube_in rejects - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Fix some corner cases that cube_in rejects
Date
Msg-id CAM-w4HOLEejnJxTYTn=j8XjQJfYoh1Z+k711cfLkPSAi0HzyhQ@mail.gmail.com
Whole thread Raw
In response to Fix some corner cases that cube_in rejects  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fix some corner cases that cube_in rejects  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Martín Marqués
Date:
Subject: Re: pg_dump with tables created in schemas created by extensions
Next
From: Tom Lane
Date:
Subject: Re: Fix some corner cases that cube_in rejects