From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Add Postgres module info |
Date: | 2024-12-11 08:35:43 |
Message-ID: | dd4d1b59-d0fe-49d5-b28f-1e463b68fa32@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
v0-0001-Introduce-MODULE_INFO-macro.patch | text/plain | 10.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2024-12-11 08:38:23 | Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility. |
Previous Message | Daniel Gustafsson | 2024-12-11 08:13:35 | Re: Serverside SNI support in libpq |