PG 13 trusted extensions and pg_available_extensions
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t134614psql -h localhost -U postgresBuilt from patchset v5 (message #5), July 27, 2026 at 06:30 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t134614_5 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t134614_5 && git checkout t134614_5Patchset v5 (message #5) is on t134614_5
Hi,
I was playing a bit with trusted extensions and wondered if there is a reason that the "trusted" flag is not exposed in pg_available_extensions.
I believe that information would be quite useful so one can easily identify extensions that can be installed as "normal" user.
Regards
Daniel
On Wed, Sep 23, 2020 at 03:28:45PM +0000, Daniel Westermann (DWE) wrote:
I was playing a bit with trusted extensions and wondered if there is
a reason that the "trusted" flag is not exposed in pg_available_extensions.
I believe that information would be quite useful so one can easily
identify extensions that can be installed as "normal" user.
Adding the trusted flag makes sense for visibility. There is a bit
more that we could consider though? For example, what about
"relocatable" and "requires"?
--
Michael
On Thu, Sep 24, 2020 at 10:58 AM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Sep 23, 2020 at 03:28:45PM +0000, Daniel Westermann (DWE) wrote:
I was playing a bit with trusted extensions and wondered if there is
a reason that the "trusted" flag is not exposed in pg_available_extensions.
I believe that information would be quite useful so one can easily
identify extensions that can be installed as "normal" user.Adding the trusted flag makes sense for visibility. There is a bit
more that we could consider though? For example, what about
"relocatable" and "requires"?
+1, and also the schema (for non relocatable extensions).
On Thu, Sep 24, 2020 at 10:58 AM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Sep 23, 2020 at 03:28:45PM +0000, Daniel Westermann (DWE) wrote:
I was playing a bit with trusted extensions and wondered if there is
a reason that the "trusted" flag is not exposed in pg_available_extensions.
I believe that information would be quite useful so one can easily
identify extensions that can be installed as "normal" user.Adding the trusted flag makes sense for visibility. There is a bit
more that we could consider though? For example, what about
"relocatable" and "requires"?
+1, and also the schema (for non relocatable extensions).
+1
On Fri, Sep 25, 2020 at 2:51 PM Daniel Westermann (DWE)
<daniel.westermann@dbi-services.com> wrote:
On Thu, Sep 24, 2020 at 10:58 AM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Sep 23, 2020 at 03:28:45PM +0000, Daniel Westermann (DWE) wrote:
I was playing a bit with trusted extensions and wondered if there is
a reason that the "trusted" flag is not exposed in pg_available_extensions.
I believe that information would be quite useful so one can easily
identify extensions that can be installed as "normal" user.Adding the trusted flag makes sense for visibility. There is a bit
more that we could consider though? For example, what about
"relocatable" and "requires"?+1, and also the schema (for non relocatable extensions).
So, apparently pg_available_extension_versions already had those
fields so all the required infrastructure was already there. I just
added the exact same fields to pg_available_extensions, see attached
patch.
Julien Rouhaud <rjuju123@gmail.com> writes:
So, apparently pg_available_extension_versions already had those
fields so all the required infrastructure was already there. I just
added the exact same fields to pg_available_extensions, see attached
patch.
The reason that pg_available_extensions has only the fields it has
is that these other values are potentially extension-version-dependent.
I do not think we can accept this patch.
(Strictly speaking, the "comment" might be version-specific too, but
there's less chance of printing a critically misleading value there.)
regards, tom lane
On Sat, Sep 26, 2020 at 10:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Julien Rouhaud <rjuju123@gmail.com> writes:
So, apparently pg_available_extension_versions already had those
fields so all the required infrastructure was already there. I just
added the exact same fields to pg_available_extensions, see attached
patch.The reason that pg_available_extensions has only the fields it has
is that these other values are potentially extension-version-dependent.
I do not think we can accept this patch.
Oh, I didn't know there could be multiple control files per extension,
and I missed the "aux" reference. So indeed this patch is
unacceptable.