Re: Include extension path on pg_available_extensions

From: Quan Zongliang <quanzongliang(at)yeah(dot)net>
To: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Include extension path on pg_available_extensions
Date: 2025-10-23 00:19:46
Message-ID: 45555a7a-f987-44d5-9f8a-593063f37ae2@yeah.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/16/25 8:18 AM, Matheus Alcantara wrote:

> Any opinions on this?
>
> [1] https://www.postgresql.org/message-id/CAKFQuwbR1Fzr8yRuMW%3DN1UMA1cTpFcqZe9bW_-ZF8%3DBa2Ud2%3Dw%40mail.gmail.com
>
Just as the discussion here. Adding extension location is a good idea.
Suppose there is an amcheck 1.5 located in the $system directory. There
is also an amcheck 1.4.5 located in another path.

Strange results will then occur:
postgres=# SHOW extension_control_path;
extension_control_path
------------------------
$system
(1 row)

postgres=# CREATE EXTENSION amcheck;
CREATE EXTENSION
postgres=# select * from pg_available_extensions;

name | default_version |
installed_version | comment | location
------------+-----------------+-------------------+--------------------------------------------+----------
amcheck | 1.5 | 1.5 | functions for
verifying relation integrity | $system

This seems to be fine.

However, if another path is added, strange results will occur.

postgres=# SET extension_control_path TO
'/Users/quanzl/build/pg-availext:$system';
SET
postgres=# select * from pg_available_extensions;
name | default_version | installed_version |
comment | location
------------+-----------------+-------------------+--------------------------------------------+-------------------------------------------
amcheck | 1.4.5 | 1.5 | functions for
verifying relation integrity | /Users/quanzl/build/pg-availext/extension

The results shown here will cause confusion. It is better to show the
path used at creation.

So, it would be a better option to add a new column to the pg_extension
table.

--
Quan Zongliang

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-10-23 00:27:51 Re: Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array
Previous Message Michael Paquier 2025-10-23 00:01:32 Re: Skip unregistered custom kinds on stats load