On Thu, Dec 12, 2024 at 3:41 PM Andrei Lepikhov <lepihov@gmail.com> wrote:
On 12/12/24 08:36, Tom Lane wrote: > Andrei Lepikhov <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.
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].
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?
