Re: Add Postgres module info - Mailing list pgsql-hackers

On 12/12/24 21:02, Yurii Rashkovskii wrote:
> On Thu, Dec 12, 2024 at 3:41 PM Andrei Lepikhov <lepihov@gmail.com 
> <mailto:lepihov@gmail.com>> wrote:
> 
>     On 12/12/24 08:36, Tom Lane wrote:
>      > Andrei Lepikhov <lepihov@gmail.com <mailto:lepihov@gmail.com>>
>     writes:
>      >> 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.
>      >
>      > Surely.  But I don't see a need for two separately-looked-up
>      > physical structures.  Seems to me it's sufficient to put the
>      > ABI-checking fields into a sub-struct within the magic block.
>     Okay, I've rewritten the patch to understand how it works. It seems to
>     work pretty well. I added separate fields for minor and major versions.
> 
> 
> I am keenly interested in helping in this area; as you have mentioned, 
> I've done similar work using an extension.
> 
> Some thoughts/questions:
> 
> 1. Do we need to latch onto the "magic" structure here? Have we 
> considered an opportunity to create a separate metadata slot that looks 
> something like `PG_MODULE_INFO(.version = ...)`. My impression of module 
> magic was that it should rather be populated during the build – to 
> provide build-time information. MODULE_INFO would be a rather 
> informational section supplied by the developer.
It has already been debated above. I may agree with colleagues that 
maintainer-provided information should be stored in the magic field to 
reduce noise.
At the same time, we use a single code part to load all that data into 
the DynamicFileList. That looks pretty well, isn't it?
> 
> 2. Any reasons to dictate MAJ.MIN format? With semantic versioning 
> abound, it's rather common to use MAJ.MIN.PATCH. There are also other 
> extensions to it (like pre-releases, builds, etc.). All of these 
> indicate distinct versions. The differences between them can be figured 
> out using semver or other parsers. Pure PL/pgSQL implementations of that 
> exist [1].
Okay, thanks; that's a good catch. I wonder how to follow these rules 
with a static fixed-sized structure. I would like to read about any 
suggestions and implementation examples.
> 
> 3. In my work, I also introduced the concept of stable module identity – 
> a unique string (for example, UUID) that represents the identity of the 
> module even if its name is going to change. Admittedly, this is not _the 
> most common_ type of problem, but I anticipate it becoming more of an 
> issue with the growth of the extension ecosystem, potential name 
> clashes, and renamings. With this approach, developers assign this 
> unique string to a module once at the beginning and never change it. 
> Have you considered this?
This option just needs some live examples. I think, if necessary, it 
could be added later.

-- 
regards, Andrei Lepikhov