Re: [HACKERS] Fix some corner cases that cube_in rejects

2016-09-27 Thread Tom Lane 
Amul Sul  writes:
> The following review has been posted through the commitfest application:
> make installcheck-world:  tested, passed
> Implements feature:   tested, passed
> Spec compliant:   tested, passed
> Documentation:not tested

> Note for committer :  There are unnecessary files (cube_1.out, cube_2.out & 
> cube_3.out) in contrib directory, that need to be removed at code checkin,  
> other than this concern, I think this patch looks pretty reasonable. Thanks.

Thanks for the review --- pushed.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fix some corner cases that cube_in rejects

2016-09-27 Thread Amul Sul 
The following review has been posted through the commitfest application:
make installcheck-world:  tested, passed
Implements feature:   tested, passed
Spec compliant:   tested, passed
Documentation:not tested

Note for committer :  There are unnecessary files (cube_1.out, cube_2.out & 
cube_3.out) in contrib directory, that need to be removed at code checkin,  
other than this concern, I think this patch looks pretty reasonable. Thanks.

Regards,
Amul

The new status of this patch is: Ready for Committer

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fix some corner cases that cube_in rejects

2016-08-29 Thread Tom Lane 
Greg Stark  writes:
> On Mon, Aug 29, 2016 at 7:19 PM, Tom Lane  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.

Nothing really.  cube_out works fine.  The point of substituting
float8out_internal is mostly to make sure we get platform-independent
spellings for inf and nan.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fix some corner cases that cube_in rejects

2016-08-29 Thread Greg Stark 
On Mon, Aug 29, 2016 at 7:19 PM, Tom Lane  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers