Re: Greatest Common Divisor - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Greatest Common Divisor
Date
Msg-id CA+TgmoawEkaMPastV0344zn9VOjDEY2UkGy-FA+60B_1y9-b4Q@mail.gmail.com
Whole thread Raw
In response to Re: Greatest Common Divisor  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: Greatest Common Divisor  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
On Fri, Jan 3, 2020 at 1:57 PM Chapman Flack <chap@anastigmatix.net> wrote:
> 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?

I guess, but it seems like a patch whose mandate is to add one or two
functions should not be burdened with inventing an entirely new way to
do extensibility. Also, I'm not entirely sure that really addresses
all the concerns. Part of my concern about continually adding new
functions to core comes from the fact that it bloats the core code,
and moving things to another schema does not help with that. It does
potentially help with the namespace pollution issue, but how much of
an issue is that anyway? Unless you've set up an unusual search_path
configuration, your own schemas probably precede pg_catalog in your
search path, besides which it seems unlikely that many people have a
gcd() function that does anything other than take the greatest common
divisor.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: Greatest Common Divisor
Next
From: Fabien COELHO
Date:
Subject: Re: Greatest Common Divisor