Re: Add Postgres module info
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-12-12T00:49:32Z
Lists: pgsql-hackers
On 12/12/2024 01:21, 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. But I would like to > object to the way you've gone about it, namely to copy-and-paste > the magic-block mechanism. That doesn't scale: the next time > somebody else wants some more fields, will we have three such > structs? It makes sense. But I want to clarify that I avoided changing PG_MODULE_MAGIC because the newly introduced structure has a totally different purpose and usage logic: the struct is designed to check compatibility, but module info isn't connected to the core version at all: a single version of the code may be built for multiple PG versions. At the same time, various versions of the same library may be usable with the same core. From the coding point of view, I agree that your approach is more laconic and reasonable. I will rewrite the code using this approach. -- regards, Andrei Lepikhov
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