Re: Add Postgres module info

On 12/12/24 21:02, Yurii Rashkovskii wrote:
> On Thu, Dec 12, 2024 at 3:41 PM Andrei Lepikhov <lepihov(at)gmail(dot)com
> <mailto:lepihov(at)gmail(dot)com>> wrote:
>
> On 12/12/24 08:36, Tom Lane wrote:
> > Andrei Lepikhov <lepihov(at)gmail(dot)com <mailto:lepihov(at)gmail(dot)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