Re: Add Postgres module info

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

In response to

Responses

Browse pgsql-hackers by date

  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