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 |
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 |