From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chapman Flack <chap@anastigmatix.net>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions
Date: Thu, 07 Nov 2019 15:00:37 -0500
Message-ID: <2585.1573156837@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, chap@anastigmatix.net, sfrost@snowman.net, peter.eisentraut@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions
In-Reply-To: <2585.1573156837@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox