| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Chapman Flack <chap(at)anastigmatix(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Greatest Common Divisor |
| Date: | 2020-01-03 15:22:02 |
| Message-ID: | 18358.1578064922@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 2020-01-02 15:50, Dean Rasheed wrote:
>> Out of curiosity, what was the original use-case for this?
> Yeah, I'm wondering, is this useful for any typical analytics or
> business application? Otherwise, abstract algebra functionality seems a
> bit out of scope.
Nobody complained when we added sinh, cosh, tanh, asinh, acosh, atanh
last year, so I'm feeling skeptical of claims that gcd should be out
of scope.
Now, those functions were just exposing libc functionality, so there
wasn't a lot of code to write. There might be a good argument that
gcd isn't useful enough to justify the amount of code we'd have to
add (especially if we allow it to scope-creep into needing to deal
with "numeric" calculations). But I'm not on board with just
dismissing it as uninteresting.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2020-01-03 16:03:15 | Re: distinguish index cost component from table component |
| Previous Message | Jehan-Guillaume de Rorthais | 2020-01-03 15:11:38 | Re: Fetching timeline during recovery |