Re: Greatest Common Divisor - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Greatest Common Divisor
Date
Msg-id 16242.1577977961@sss.pgh.pa.us
Whole thread Raw
In response to Re: Greatest Common Divisor  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Greatest Common Divisor  (Vik Fearing <vik.fearing@2ndquadrant.com>)
Re: Greatest Common Divisor  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Dean Rasheed (dean.a.rasheed@gmail.com) wrote:
>> I'm not objecting to adding it, I'm just curious. In fact, I think
>> that if we do add this, then we should probably add lcm() at the same
>> time, since handling its overflow cases is sufficiently non-trivial to
>> justify not requiring users to have to implement it themselves.

> I tend to agree with this.

Does this impact the decision about whether we need a variant for
numeric?  I was leaning against that, primarily because (a)
it'd introduce a set of questions about what to do with non-integral
inputs, and (b) it'd make the patch quite a lot larger, I imagine.
But a variant of lcm() that returns numeric would have much more
resistance to overflow.

Maybe we could just define "lcm(bigint, bigint) returns numeric"
and figure that that covers all cases, but it feels slightly
weird.  You couldn't do lcm(lcm(a,b),c) without casting.
I guess that particular use-case could be addressed with
"lcm(variadic bigint[]) returns numeric", but that's getting
really odd.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Greatest Common Divisor
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Fix parallel query doc typos