Re: Infinities in type numeric

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Infinities in type numeric
Date: 2020-06-16 17:24:56
Message-ID: 1368929.1592328296@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Fri, 12 Jun 2020 at 02:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> * I had to invent some semantics for non-standardized functions,
>> particularly numeric_mod, numeric_gcd, numeric_lcm. This area
>> could use review to be sure that I chose desirable behaviors.

> I think the semantics you've chosen for numeric_mod() are reasonable,
> and I think they're consistent with POSIX fmod().

Ah, I had not thought to look at fmod(). I see that POSIX treats
x-is-infinite the same as y-is-zero: raise EDOM and return NaN.
I think it's okay to deviate to the extent of throwing an error in
one case and returning NaN in the other, but I added a comment
noting the difference.

> Similar arguments apply to lcm(), so I'd say that both gcd() and lcm()
> should return 'NaN' if either input is 'Inf' or 'NaN'.

Works for me; that's easier anyway.

The attached v3 patch fixes these things and also takes care of an
oversight in v2: I'd made numeric() apply typmod restrictions to Inf,
but not numeric_in() or numeric_recv(). I believe the patch itself
is in pretty good shape now, though there are still some issues
elsewhere as noted in the first message in this thread.

Thanks for reviewing!

regards, tom lane

Attachment Content-Type Size
numeric-infinities-3.patch text/x-diff 119.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2020-06-16 17:49:59 PostgreSQL 13 Beta 2 Release Date
Previous Message Robert Haas 2020-06-16 17:14:11 Re: Parallel Seq Scan vs kernel read ahead