|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|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|