From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chapman Flack <chap@anastigmatix.net>
cc: Stephen Frost <sfrost@snowman.net>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions
In-reply-to: <929c2c97-569b-e626-7289-0bbea4d0012b@anastigmatix.net>
References: <5889.1566415762@sss.pgh.pa.us>
 <c15c0f58-79a9-4051-1f43-8fc06564df69@2ndquadrant.com>
 <27727.1573052802@sss.pgh.pa.us> <20191107183856.GY6962@tamriel.snowman.net>
 <31658.1573152852@sss.pgh.pa.us> <20191107191320.GZ6962@tamriel.snowman.net>
 <929c2c97-569b-e626-7289-0bbea4d0012b@anastigmatix.net>
Comments: In-reply-to Chapman Flack <chap@anastigmatix.net>
	message dated "Thu, 07 Nov 2019 14:40:57 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2584.1573156837.1@sss.pgh.pa.us>
Date: Thu, 07 Nov 2019 15:00:37 -0500
Message-ID: <2585.1573156837@sss.pgh.pa.us>
Precedence: bulk

Chapman Flack <chap@anastigmatix.net> writes:
> So isn't this more a proposal to add another boolean attribute
> to pg_authid, along the lines of rolcreatedb or rolbypassrls?

I think we've mostly concluded that default roles are superior
to pg_authid attributes.  The latter are legacy things rather
than a model to keep extending.

> On the other hand, maybe thinking of it as a privilege bit could
> lead somewhere interesting. A not-yet-installed extension isn't
> a real database object, but it does have a synthesized existence
> as a row in the pg_available_extensions view. Maybe that could
> have an acl column, where a privilege (why not just CREATE?) could
> be granted to one or more roles. Synthesizing that could rely on
> some directive in the control file, or in some separate
> extension_creators.conf file that would associate extensions with
> roles.

Meh ... that seems like building a whole new set of infrastructure
to solve something that we already have a couple of good models
for (i.e., default roles and object-based permissions).  I really
doubt it's worth the trouble to do that.

Although upthread I mentioned the possibility of a database admin
editing extension control files, I think most people would consider
that to be a truly last resort; you generally want those files to
remain as-distributed.  The alternative of a new config file is
slightly less unmaintainable, but only slightly.  There'd be no
way to update it from inside the database, short of writing a lot
of new infrastructure comparable to ALTER SYSTEM, and surely we
don't want to do that.

> Maybe that's just a more ad-hoc and GUCless way of circling back
> to what the original proposal would be doing with GUCs....

Yeah, I think if we really need per-extension configurability
of this, we're going to end up with a GUC.  It's just not worth
the trouble to build another mechanism that would support such a
need.  But I'm currently taking the position that we don't need
to support that.

			regards, tom lane