Re: Marking some contrib modules as trusted extensions - Mailing list pgsql-hackers

From Sandro Santilli
Subject Re: Marking some contrib modules as trusted extensions
Date
Msg-id 20200226081121.GA5242@liz
Whole thread Raw
In response to Re: Marking some contrib modules as trusted extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Marking some contrib modules as trusted extensions
List pgsql-hackers
On Thu, Feb 13, 2020 at 07:09:18PM -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres@anarazel.de> writes:
> >> It seems to me that FROM UNPACKAGED shouldn't support trusted.
> 
> > Hmm, seems like a reasonable idea, but I'm not quite sure how to mechanize
> > it given that "unpackaged" isn't magic in any way so far as extension.c
> > is concerned.  Maybe we could decide that the time for supporting easy
> > updates from pre-9.1 is past, and just remove all the unpackaged-to-XXX
> > scripts?  Maybe even remove the "FROM version" option altogether.
> 
> [ thinks some more... ]  A less invasive idea would be to insist that
> you be superuser to use the FROM option.  But I'm thinking that the
> unpackaged-to-XXX scripts are pretty much dead letters anymore.  Has
> anyone even tested them in years?  How much longer do we want to be
> on the hook to fix them?

PostGIS uses unpackaged-to-XXX pretty heavily, and has it under
automated testing (which broke since "FROM unpackaged" support was
removed, see 14514.1581638958@sss.pgh.pa.us)

We'd be ok with requiring SUPERUSER for doing that, since that's
what is currently required so nothing would change for us.

Instead, dropping UPGRADE..FROM completely puts us in trouble of
having to find another way to "package" postgis objects.

--strk;



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: truncating timestamps on arbitrary intervals
Next
From: David Fetter
Date:
Subject: Re: Use compiler intrinsics for bit ops in hash