|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|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|