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
- v7-0001-Introduce-PG_MODULE_MAGIC_EXT-macro.patch (text/x-diff) patch v7-0001
- v7-0002-Use-PG_MODULE_MAGIC_EXT-in-our-installable-librar.patch (text/x-diff) patch v7-0002
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
-
Avoid mixing designated and non-designated field initializers.
- d66997dfe8fe 18.0 landed
-
Use PG_MODULE_MAGIC_EXT in our installable shared libraries.
- 55527368bd07 18.0 landed
-
Introduce PG_MODULE_MAGIC_EXT macro.
- 9324c8c58065 18.0 landed