Re: Removing pg_pltemplate and creating "trustable" extensions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions
Date: 2020-01-10 22:53:10
Message-ID: 27618.1578696790@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> To be clear, I was advocating for a NEW DB-level privilege ('INSTALL' or
> 'CREATE EXTENSION' if we could make that work), so that we have it be
> distinct from CREATE (which, today, really means 'CREATE SCHEMA').

I still say this is wrong, or at least pointless, because it'd be a
right that any DB owner could grant to himself. If we're to have any
meaningful access control on extension installation, the privilege
would have to be attached to some other object ... and there's no clear
candidate for what. As someone noted awhile back, if we could somehow
attach ACLs to potentially-installable extensions, that might be an
interesting avenue to pursue. That's well beyond what I'm willing
to pursue for v13, though.

In the meantime, though, this idea as stated doesn't do anything except
let a DB owner grant install privileges to someone else. I'm not even
convinced that we want that, or that anyone needs it (I can recall zero
such requests related to PLs in the past). And for sure it does not
belong in a minimal implementation of this feature.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-01-11 00:03:23 Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema
Previous Message Alvaro Herrera 2020-01-10 21:37:07 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions