Re: Add Postgres module info

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andrei Lepikhov <lepihov@gmail.com>, Michael Paquier <michael@paquier.xyz>, Alexander Korotkov <aekorotkov@gmail.com>, Yurii Rashkovskii <yrashk@omnigres.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-03-24T15:54:17Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.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.)

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.

			regards, tom lane



Commits

  1. Avoid mixing designated and non-designated field initializers.

  2. Use PG_MODULE_MAGIC_EXT in our installable shared libraries.

  3. Introduce PG_MODULE_MAGIC_EXT macro.