Re: Greatest Common Divisor

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Greatest Common Divisor
Дата
Msg-id 16242.1577977961@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Greatest Common Divisor  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Greatest Common Divisor
Re: Greatest Common Divisor
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Greatest Common Divisor
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Fix parallel query doc typos