Re: Marking some contrib modules as trusted extensions

From: Sandro Santilli <strk(at)kbt(dot)io>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Marking some contrib modules as trusted extensions
Date: 2020-02-26 08:11:21
Message-ID: 20200226081121.GA5242@liz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Feb 13, 2020 at 07:09:18PM -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres(at)anarazel(dot)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(dot)1581638958(at)sss(dot)pgh(dot)pa(dot)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.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2020-02-26 08:12:24 Re: Use compiler intrinsics for bit ops in hash
Previous Message David Fetter 2020-02-26 07:51:08 Re: truncating timestamps on arbitrary intervals