Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jun 11, 2020 at 9:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> We had a discussion recently about how it'd be a good idea to support
>> infinity values in type numeric [1].
> FWIW, I don't particularly like the idea. Back when I was an
> application developer, I remember having to insert special cases into
> any code that dealt with double precision to deal with +/-Inf and NaN.
> I was happy that I didn't need them for numeric, too. So this change
> would have made me sad.
Well, you're already stuck with special-casing numeric NaN, so I'm
not sure that Inf makes your life noticeably worse on that score.
This does tie into something I have a question about in the patch's
comments though. As the patch stands, numeric(numeric, integer)
(that is, the typmod-enforcement function) just lets infinities
through regardless of the typmod, on the grounds that it is/was also
letting NaNs through regardless of typmod. But you could certainly
make the argument that Inf should only be allowed in an unconstrained
numeric column, because by definition it overflows any finite precision
restriction. If we did that, you'd never see Inf in a
standard-conforming column, since SQL doesn't allow unconstrained
numeric columns IIRC. That'd at least ameliorate your concern.
If we were designing this today, I think I'd vote to disallow NaN
in a constrained numeric column, too. But I suppose it's far too
late to change that aspect.
regards, tom lane