Add Postgres module info
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-12-11T08:35:43Z
Lists: pgsql-hackers
Attachments
- v0-0001-Introduce-MODULE_INFO-macro.patch (text/plain) patch v0-0001
Hi, 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. As I see, this question was already debated during the introduction of PG_MODULE_MAGIC [1], and developers didn't add such data because the practical case wasn't obvious. Right now, when multiple extensions are maintained and used in installations constantly, we have enough information to continue this discussion. The idea was initially born with the support of the extension, which had a stable UI and frequently changing library code. To answer customer requests, it was necessary to know the specific version of the code to reproduce the situation in a test environment. That required introducing a file naming rule and a specific exported variable into the module code. However, this is not a sufficient guarantee of version determination and complicates the technical process when supporting many extensions obtained from different sources. Another example is a library without an installation script at all - see auto_explain. Without a 'CREATE EXTENSION' call, we don't have an option to find out the library's version. It would be much easier if the Postgres catalogue contained a function, for example, module_info(module_name), which would allow you to determine the file's full path and name containing the desired module in the psql console and its version. On the other hand, the Omnigres project (author Yurii Rashkovski) also came up with the idea of module versioning, although it does this externally out of the Postgres core. When designing this code, I also adopted ideas from this repository. So, let me propose a patch that introduces this tiny feature: the maintainer can add the PG_MODULE_INFO macro to the library code, and Postgres reads it on the module's load. There is a question of how much information makes sense to add to the module. For now, each time I prepare extensions to release, I have to add the extension name (to avoid issues with file naming/renaming) and the version. Format of the version storage? Do we need a separate minor version number? It is a subject to debate. [1] https://www.postgresql.org/message-id/flat/20060507211705.GB3808%40svana.org -- 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