Re: Fix some corner cases that cube_in rejects

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix some corner cases that cube_in rejects
Date: 2016-08-29 19:54:18
Message-ID: 18779.1472500458@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martín Marqués 2016-08-29 20:43:07 Re: pg_dump with tables created in schemas created by extensions
Previous Message Greg Stark 2016-08-29 19:44:56 Re: Fix some corner cases that cube_in rejects