Re: Add Postgres module info

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Andrei Lepikhov" <lepihov(at)gmail(dot)com>, "Michael Paquier" <michael(at)paquier(dot)xyz>, "Alexander Korotkov" <aekorotkov(at)gmail(dot)com>, "Yurii Rashkovskii" <yrashk(at)omnigres(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add Postgres module info
Date: 2025-03-24 18:14:23
Message-ID: f8608216-61d7-4885-b215-91e9d176386c@app.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 24, 2025, at 12:54 PM, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > It looks reasonable to me. I am a bit worried that using PG_VERSION as
> > the version string is going to feel like the wrong thing at some
> > stage, but I can't really say why, and I think it's better to do
> > something now and maybe have to revise it later than to do nothing now
> > and hope that we come up with a brilliant idea at some point in the
> > future.
>
> Agreed. I think something is clearly better than nothing here, and
> PG_VERSION has the huge advantage that we need no new mechanism to
> maintain it. (A version identifier that isn't updated when it needs
> to be is worse than no identifier, IMO.)

Agreed. My only concern is that people can confuse this version with the one
available in pg_extension or pg_available_extension* functions.

> If somebody thinks of a better idea and is willing to do the legwork
> to make it happen, we can surely change to something else later on.
> Or invent another field with different semantics, or whatever.

I think those modules without control file, it is natural to use PG_VERSION.
However, I'm concerned that users can confuse the version if we provide
PG_VERSION as version and the extension catalog says something different.

postgres=# select * from pg_available_extensions where name = 'plperl';
name | default_version | installed_version | comment
--------+-----------------+-------------------+-----------------------------
plperl | 1.0 | | PL/Perl procedural language
(1 row)

postgres=# load 'plperl';
LOAD
postgres=# select * from pg_get_loaded_modules();
module_name | version | file_name
-------------+---------+-----------
plperl | 18devel | plperl.so
(1 row)

Maybe a note into default_version [1] is sufficient to clarify or a mechanism
to grab the information from control file and expose it as a macro. (I attached
an idea to accomplish this goal although it lacks meson support.) Thoughts?

I played with it a bit and it seems good to go.

postgres=# select version();
version
----------------------------------------------------------------------------------------------
PostgreSQL 18devel on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
(1 row)

postgres=# select * from pg_get_loaded_modules();
module_name | version | file_name
-------------+---------+-----------
(0 rows)

postgres=# load 'wal2json';
LOAD
postgres=# select * from pg_get_loaded_modules();
module_name | version | file_name
-------------+---------+-------------
wal2json | 2.6 | wal2json.so
(1 row)

Code:

diff --git a/wal2json.c b/wal2json.c
index 0c6295d..1f439be 100644
--- a/wal2json.c
+++ b/wal2json.c
@@ -40,7 +40,14 @@
#define WAL2JSON_FORMAT_VERSION 2
#define WAL2JSON_FORMAT_MIN_VERSION 1

+#if PG_VERSION_NUM >= 180000
+PG_MODULE_MAGIC_EXT(
+ .name = "wal2json",
+ .version = WAL2JSON_VERSION
+);
+#else
PG_MODULE_MAGIC;
+#endif

[1] https://www.postgresql.org/docs/current/extend-extensions.html

--
Euler Taveira
EDB https://www.enterprisedb.com/

Attachment Content-Type Size
autoversion.patch.nocfbot application/octet-stream 805 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-03-24 18:24:34 Re: Add Postgres module info
Previous Message Nikolay Shaplov 2025-03-24 18:03:11 Re: vacuum_truncate configuration parameter and isset_offset