Re: Greatest Common Divisor - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Greatest Common Divisor
Date
Msg-id CAHyXU0zU5Q=tk8VnkQ6gbi6=9rKLKHO3kyj4LWL95pu9AyabgQ@mail.gmail.com
Whole thread Raw
In response to Re: Greatest Common Divisor  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Greatest Common Divisor  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Jan 3, 2020 at 10:24 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, Jan 3, 2020 at 10:23 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > 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.
>
> Yeah. There's always the question with things like this as to whether
> we ought to push certain things into contrib modules that are not
> installed by default to avoid bloating the set of things built into
> the core server. But it's hard to know where to draw the line.

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.
Ideally, the public namespace should contain (by default) only sql
standard functions with all non-standard material in an appropriate
extension.  Already released material is obviously problematic and
needs more thought but we ought to at least stop making the problem
worse if possible.

merlin



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgsql: Add basic TAP tests for psql's tab-completion logic.
Next
From: Robert Haas
Date:
Subject: Re: color by default