On 6/12/20 7:00 PM, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Jun 11, 2020 at 9:16 PM Tom Lane <t...@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.
It does. The precision and scale are both optional. If the precision is missing, it's implementation defined; if the scale is missing, it's 0. -- Vik Fearing
