Re: Removing pg_pltemplate and creating "trustable" extensions - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Removing pg_pltemplate and creating "trustable" extensions
Date
Msg-id CA+TgmoYry3gSXN98s8hVyf8GVzTuqV8WuhCvpxNzMFEOdvx84w@mail.gmail.com
Whole thread Raw
In response to Re: Removing pg_pltemplate and creating "trustable" extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Removing pg_pltemplate and creating "trustable" extensions  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Fri, Jan 10, 2020 at 2:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, the other direction we could go here, which I guess is what
> you are arguing for, is to forget the new default role and just
> say that marking an extension trusted allows it to be installed by
> DB owners, full stop.  That's nice and simple and creates no
> backwards-compatibility issues.  If we later decide that we want
> a default role, or any other rules about who-can-install, we might
> feel like this was a mistake --- but the backwards-compatibility issues
> we'd incur by changing it later are exactly the same as what we'd have
> today if we do something different from this.  The only difference
> is that there'd be more extensions affected later (assuming we mark
> more things trusted).

I agree with your analysis, but I'm still inclined to feel that the
new pre-defined roll is a win.

Generally, decoupled permissions are better. Being able to grant
someone either A or B or both or neither is usually superior to having
to grant either both permissions or neither.

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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: our checks for read-only queries are not great
Next
From: Stephen Frost
Date:
Subject: Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI?)