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+TgmoYbsVCHNkX0g5QTZS=fgf9AXYoXHT2_4Jy6gpEFD5yBXQ@mail.gmail.com
Whole thread Raw
In response to Re: Removing pg_pltemplate and creating "trustable" extensions  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Removing pg_pltemplate and creating "trustable" extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jan 9, 2020 at 11:30 AM Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
> > On Thu, Jan 9, 2020 at 10:09 AM Stephen Frost <sfrost@snowman.net> wrote:
> > > [ wall of text ]
>
> This really isn't helpful.

Sorry.

That being said, I'm pretty tired of writing emails that say the same
thing over and over again and having you write long responses that
don't seem to actually respond to the points being raised in the
email.

Like:

> > I don't see anything in here I really disagree with, but nor do I
> > understand why any of it means that giving superusers the ability to
> > customize which extensions are database-owner-installable would be a
> > bad thing.
>
> Alright, I think there's definitely something we need to sort through.
>
> If you agree that the approach I advocated means less code for hosting
> providers to have to change in their fork, and that they don't want to
> give users superuser, and that they want non-superusers to be able to
> install extensions, and that they really don't want to modify things
> post-install, then I don't get why you're against the DB-level privilege
> that I've been advocating for except that it's "not as customizable."

What I was writing about in the quoted paragraph and what you are
writing about in the response are two different things. I said
*nothing* about a DB-level privilege in the paragraph I wrote, and yet
somehow your response to that paragraph says that I'm opposing a
DB-level privilege.

> Are you saying that in order to have something here that we must make it
> so that a superuser is able to specifiy, individually, which extensions
> can be installed by which users?  You keep coming back to this point of
> saying that you want this to be 'customizable' but I really don't see
> any justification for the level of customization you're asking for- but
> I see an awful lot of work involved.  When there's a lot of work
> involved for a use-case that no one is actually asking for, I'm really
> skeptical.  The use-cases that you've presented, at least thus far,
> certainly haven't swayed me into thinking that you're right that there's
> a justifiable use-case here for this level of complicated privileges.

I set forth my exact views in
http://postgr.es/m/CA+TgmoZK=5EC2O13J3sfOUCvYtvjGtxUKg=wQ11Q-wy4sc4b+g@mail.gmail.com

Everything since then has been trying to somehow clarify what I wrote
in that email, which has resulted in me repeating everything I said
there several times in different words. I would like to stop doing
that now. It appears to be clarifying nothing, failing to advance the
patch, and irritating you.

> I'm also not convinced that such a design would even be practical- ...

Again, as I said upthread, Tom had the exact feature about which I am
talking in the first version of the patch. That is a strong argument
in favor of it being practical. It's also a pretty good argument that
it is at least potentially useful, because Tom doesn't usually do
useless things for no reason.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add pg_file_sync() to adminpack
Next
From: Tom Lane
Date:
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions