Horton

Re: Greatest Common Divisor

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Chapman Flack <chap@anastigmatix.net>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Dean Rasheed <dean.a.rasheed@gmail.com>, Vik Fearing <vik.fearing@2ndquadrant.com>, Fabien COELHO <coelho@cri.ensmp.fr>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-01-03T21:10:43Z
Lists: pgsql-hackers 
On 2020-Jan-03, Merlin Moncure wrote:

> On Fri, Jan 3, 2020 at 1:32 PM Robert Haas <robertmhaas@gmail.com> wrote:

> > True, but because of the way search_path is typically set, they'd
> > probably continue to get their own version anyway, so I'm not sure
> > what the problem is.
> 
> Is that right? Default search_path is for pg_catalog to resolve before
> public.  Lightly testing with a hand rolled pg_advisory_lock
> implementation that raise a notice, my default database seemed to
> prefer the build in function.  Maybe I'm not following you.

Maybe a very simple solution is indeed to have a separate pg_math or
pg_extra or whatever, which by default is *last* in the search_path.
That would make a user's gcd() be chosen preferently, if one exists.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Add functions gcd() and lcm() for integer and numeric types.