Re: Marking some contrib modules as trusted extensions

Поиск
Список
Период
Сортировка
От Sandro Santilli
Тема Re: Marking some contrib modules as trusted extensions
Дата
Msg-id 20200226081121.GA5242@liz
обсуждение исходный текст
Ответ на Re: Marking some contrib modules as trusted extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Marking some contrib modules as trusted extensions  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: truncating timestamps on arbitrary intervals
Следующее
От: David Fetter
Дата:
Сообщение: Re: Use compiler intrinsics for bit ops in hash