Horton

Re: Greatest Common Divisor

Chapman Flack <chap@anastigmatix.net>

View thread View on postgr.es
From: Chapman Flack <chap@anastigmatix.net>
To: Robert Haas <robertmhaas@gmail.com>, Merlin Moncure <mmoncure@gmail.com>
Cc: 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-03T18:57:42Z
Lists: pgsql-hackers 
On 1/3/20 1:46 PM, Robert Haas wrote:
> On Fri, Jan 3, 2020 at 1:10 PM Merlin Moncure <mmoncure@gmail.com> wrote:
>> Just stop doing it.  It's very little extra work to package an item
>> into an extension and this protects your hapless users who might have
>> implemented a function called gcd() that does something different.
>> ...
> There are counter-arguments to that, though. Maintaining a lot of
> extensions with only one or two functions in them is a nuisance.
> Having things installed by default is convenient for wanting to use
> them. Maintaining contrib code so that it works whether or not the SQL
> definitions have been updated via ALTER EXTENSION .. UPDATE takes some
> work and thought, and sometimes we screw it up.

Is there a middle ground staring us in the face, where certain things
could be added in core, but in a new schema like pg_math (pg_ !), so
if you want them you put them on your search path or qualify them
explicitly, and if you don't, you don't?

Regards,
-Chap

Commits

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