Re: Marking some contrib modules as trusted extensions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Marking some contrib modules as trusted extensions
Date: 2020-02-08 01:40:21
Message-ID: 28773.1581126021@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

After looking more closely at these modules, I'm kind of inclined
*not* to put the trusted marker on intagg. That module is just
a backwards-compatibility wrapper around functionality that
exists in the core code nowadays. So I think what we ought to be
doing with it is deprecating and eventually removing it, not
encouraging people to keep using it.

Given that and the other discussion in this thread, I think the
initial list of modules to trust is:

btree_gin
btree_gist
citext
cube
dict_int
earthdistance
fuzzystrmatch
hstore
hstore_plperl
intarray
isn
jsonb_plperl
lo
ltree
pg_trgm
pgcrypto
seg
tablefunc
tcn
tsm_system_rows
tsm_system_time
unaccent
uuid-ossp

So attached is a patch to do that. The code changes are trivial; just
add "trusted = true" to each control file. We don't need to bump the
module version numbers, since this doesn't change the contents of any
extension, just who can install it. I do not think any regression
test changes are needed either. (Note that commit 50fc694e4 already
added a test that trusted extensions behave as expected, see
src/pl/plperl/sql/plperl_setup.sql.) So it seems like the only thing
that needs much discussion is the documentation changes. I adjusted
contrib.sgml's discussion of how to install these modules in general,
and then labeled the individual modules if they are trusted.

regards, tom lane

Attachment Content-Type Size
mark-some-contrib-modules-trusted-1.patch text/x-diff 21.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message nuko yokohama 2020-02-08 02:15:45 Re: Implementing Incremental View Maintenance
Previous Message Justin Pryzby 2020-02-08 01:01:07 Re: error context for vacuum to include block number