From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Euler Taveira <euler(at)eulerto(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add Postgres module info |
Date: | 2024-12-12 03:24:39 |
Message-ID: | Z1pXd_dleBGIiVR3@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 11, 2024 at 08:34:28PM -0500, Tom Lane wrote:
> "Euler Taveira" <euler(at)eulerto(dot)com> writes:
>> +1 for the general idea. I received some reports like [1] related to wal2json
>> that people wants to obtain the output plugin version. Since it is not installed
>> via CREATE EXTENSION, it is not possible to detect what version is installed,
>> hence, some tools cannot have some logic to probe the module version. In a
>> managed environment, it is hard to figure out the exact version for
>> non-CREATE-EXTENSION modules, unless it is explicitly informed by the vendor.
>
> What would you foresee as the SQL API for inspecting a module that's
> not tied to an extension?
Rather than a function that can be called with a specific module name
in input, invent a new system SRF function that would report back for
a process all the libraries that have been loaded in it? Presumably,
the extra tracking can be done in dfmgr.c with more fields added to
DynamicFileList to track the information involved.
Being able to print the information of DynamicFileList can be argued
as useful on its own as long as its execution can be granted, with
superuser right by default.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2024-12-12 03:34:14 | Re: Fix early elog(FATAL) |
Previous Message | Michael Harris | 2024-12-12 03:14:20 | Re: FileFallocate misbehaving on XFS |