Andrei Lepikhov <lepihov@gmail.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. 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?
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.
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.
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.
5. Something I didn't think of?
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.
regards, tom lane
