On Wed, Apr 08, 2009 at 08:16:52PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
On Wed, Apr 08, 2009 at 06:11:59PM -0400, Tom Lane wrote:
Anyway, I revised this a bit and applied to HEAD.
I've not tested; but your changes look as though they will break:
SELECT
On Tue, Apr 07, 2009 at 12:51:21PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
SELECT 'NaN'::float8;
SELECT ' NaN'::float8;
SELECT 'NaN '::float8;
SELECT '+NaN'::float8;
SELECT '-NaN'::float8;
Well, the +- part must be an artifact of your strtod()
Sam Mason s...@samason.me.uk writes:
On Tue, Apr 07, 2009 at 12:51:21PM -0400, Tom Lane wrote:
IIRC, the explicit support for leading/trailing spaces is something that
we added in float8in long after numeric_in was written, and I think just
nobody thought about numeric at the time. But it's
On Wed, Apr 08, 2009 at 06:11:59PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
On Tue, Apr 07, 2009 at 12:51:21PM -0400, Tom Lane wrote:
IIRC, the explicit support for leading/trailing spaces is something that
we added in float8in long after numeric_in was written, and I
Sam Mason s...@samason.me.uk writes:
On Wed, Apr 08, 2009 at 06:11:59PM -0400, Tom Lane wrote:
Anyway, I revised this a bit and applied to HEAD.
I've not tested; but your changes look as though they will break:
SELECT 'Infinity'::float::numeric;
That gives an error now, just as it did
Hi,
I've just noticed that the NUMERIC input function special cases NaN
values differently to the floating point input functions. For example
the following are all accepted (on my system anyway):
SELECT 'NaN'::float8;
SELECT ' NaN'::float8;
SELECT 'NaN '::float8;
SELECT '+NaN'::float8;
Sam Mason s...@samason.me.uk writes:
I've just noticed that the NUMERIC input function special cases NaN
values differently to the floating point input functions. For example
the following are all accepted (on my system anyway):
SELECT 'NaN'::float8;
SELECT ' NaN'::float8;
SELECT
