From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add Postgres module info |
Date: | 2024-12-11 19:26:12 |
Message-ID: | 2qdclwljzvw5abfvo4porr3ehox32icrbtfjaum327ruxts6qm@udexcbweewpq |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2024-12-11 13:21:03 -0500, Tom Lane wrote:
> Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
> > 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.
>
> I don't have much of an opinion one way or the other about the
> usefulness of these additional info fields.
FWIW, Id like to have some more information in there, without commenting on
the specifics.
> But I would like to object to the way you've gone about it, namely to
> copy-and-paste the magic-block mechanism. That doesn't scale: the next time
> somebody else wants some more fields, will we have three such structs?
I agree with that.
> The approach we foresaw using was that we could simply add more
> fields to Pg_magic_struct (obviously, only in a major version).
> That's happened at least once already - abi_extra was not there
> to begin with.
>
> There are a couple of ways that we could deal with the API
> seen by module authors:
>
> 1. The PG_MODULE_MAGIC macro keeps the same API and leaves the
> additional field(s) empty. Authors who want to fill the
> extra field(s) use a new macro, say PG_MODULE_MAGIC_V2.
>
> 2. PG_MODULE_MAGIC gains some arguments, forcing everybody
> to change their code. While this would be annoying, it'd be
> within our compatibility rules for a major version update.
> I wouldn't do it though unless there were a compelling reason
> why everybody should fill these fields.
I'd like to avoid needing to do this again if / when we invent the next set of
optional arguments. So just having a different macro with a hardcoded set of
arguments or changing PG_MODULE_MAGIC to have a hardcoded set of arguments
doesn't seem great.
To be future proof, I think it'd be good to declare the arguments as
designated initializers. E.g. like
PG_MODULE_MAGIC_EXT(
.version = 10000,
.threadsafe = 1
);
where the macro would turn the arguments into a struct initializer inside
Pg_magic_struct.
That way we can add/remove arguments and only extensions that use
removed arguments need to change.
> 3. Maybe we could do something with making PG_MODULE_MAGIC
> variadic, but I've not thought hard about what that could
> look like. In any case it'd only be a cosmetic improvement
> over the above ways.
Yea, it'd be nice to avoid needing an _EXT or _V2. But I can't immediately
think of a way that allows a macro with no arguments and and an argument.
> 4. The extra fields are filled indirectly by macros that
> extension authors can optionally provide (a variant on the
> FMGR_ABI_EXTRA mechanism). This would be code-order-sensitive
> so I'm not sure it's really a great idea.
Agreed.
> With any of these except #4, authors who want their source code to
> support multiple PG major versions would be forced into using #if
> tests on CATALOG_VERSION_NO to decide what to write. That's a
> bit annoying but hardly unusual.
#2 would be bit more annoying than #1, I'd say, because it'd affect every
single extension, even ones not interested in any of this.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2024-12-11 19:41:47 | Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans) |
Previous Message | Masahiko Sawada | 2024-12-11 19:20:58 | Re: Unmark gen_random_uuid() function leakproof |