Re: Add Postgres module info
Euler Taveira <euler@eulerto.com>
From: "Euler Taveira" <euler@eulerto.com>
To: "Andres Freund" <andres@anarazel.de>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Andrei Lepikhov" <lepihov@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-12-12T00:49:00Z
Lists: pgsql-hackers
On Wed, Dec 11, 2024, at 4:26 PM, Andres Freund wrote: > On 2024-12-11 13:21:03 -0500, Tom Lane wrote: > > Andrei Lepikhov <lepihov@gmail.com> writes: > > > I would like to propose the module_info structure, which aims to let > > > extension maintainers sew some data into the binary file. Being included > > > in the module code, this information remains unchanged and is available > > > for reading by a backend. > > > > I don't have much of an opinion one way or the other about the > > usefulness of these additional info fields. > > FWIW, Id like to have some more information in there, without commenting on > the specifics. +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. [1] https://github.com/eulerto/wal2json/issues/181 -- Euler Taveira EDB https://www.enterprisedb.com/
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