Re: Infinities in type numeric
От | Tom Lane |
---|---|
Тема | Re: Infinities in type numeric |
Дата | |
Msg-id | 702941.1591981259@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Infinities in type numeric (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Infinities in type numeric
Re: Infinities in type numeric |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: