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
