Re: Add Postgres module info

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Alexander Korotkov <aekorotkov@gmail.com>, Yurii Rashkovskii <yrashk@omnigres.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-03-23T19:10:02Z
Lists: pgsql-hackers

Attachments

Andrei Lepikhov <lepihov@gmail.com> writes:
> On 3/22/25 23:49, Tom Lane wrote:
>> * It is not clear to me what permission restrictions we should put
>> on pg_get_loaded_modules, ...

> I vote for the idea of stripping the full path to just a filename.

Works for me.  v7 attached does it that way.

>> * I'm not happy with putting pg_get_loaded_modules into dfmgr.c.

> I just attempted to reduce number of exported objects here. If it is ok 
> to introduce an iterator, the pg_get_loaded_modules() may live in 
> extension.c

Yeah, I like that better than leaving it in dfmgr.c, so done that way.
The iterator functions also provide some cover for dealing with
on-the-fly changes of the file list, if we ever need that.

I converted pg_get_loaded_modules to run just once and deliver its
results in a tuplestore.  That's partly because the adjacent SRFs
in extension.c work like that, but mostly because it removes the
hazard of the file list changing mid-run.

>> * Should we convert our existing modules to use PG_MODULE_MAGIC_EXT?
>> I'm mildly in favor of that, but I think we'd need some automated way
>> to manage their version strings, and I don't know what that ought to
>> look like.  Maybe it'd be enough to make all the in-core modules use
>> PG_VERSION as their version string, but I think that might put a dent
>> in the idea of the version strings following semantic versioning
>> rules.

> Yes, additional burden to bump version string was a stopper for me to 
> propose such a brave idea.

After sleeping on it, I think we really ought to do that, so 0002
attached does so.

I think this version is ready to commit, if there are not objections
to the decisions mentioned above.

			regards, tom lane

Commits

  1. Avoid mixing designated and non-designated field initializers.

  2. Use PG_MODULE_MAGIC_EXT in our installable shared libraries.

  3. Introduce PG_MODULE_MAGIC_EXT macro.