Re: unsafe floats

Neil Conway <neilc(at)samurai(dot)com> writes:
> Okay, I think this would be a reasonable set of behavior:

> - define a new GUC var that controls how exceptional floating
> point values (NaN, inf, -inf) are handled.

> - by default, we still raise an error when a floating point
> operation results in NaN / inf / etc.; if the GUC var is toggled
> from its default value, no error is raised. This preserves
> backward compatibility with applications that expect floating
> point overflow to be reported, for example.

That sounds okay. Also we might want to distinguish NaN from Infinity
--- I would expect most people to want zero-divide to continue to get
reported, for instance, even if they want to get Infinity for overflow.

> - that also means that, by default, we should reject 'NaN',
> 'Infinity', and '-Infinity' as input to float4/float8: if these
> values are illegal as the result of FP operations by default, it
> seems only logical to disallow them as input to the FP types.

This I disagree with. It would mean, for example, that you could not
dump and reload columns containing such data unless you remembered to
switch the variable first. If you did this then I'd insist on pg_dump
scripts setting the variable to the permissive state. In any case,
I don't see why a restriction that certain operations can't produce a
certain value should render the value illegal overall.

regards, tom lane