Re: Removing pg_pltemplate and creating "trustable" extensions

Tom Lane <tgl@sss.pgh.pa.us>

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
Date: 2019-11-07T20:00:37Z
Lists: pgsql-hackers
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



Commits

  1. Invent "trusted" extensions, and remove the pg_pltemplate catalog.