On Mon, Feb 17, 2025 at 03:41:56AM +0200, Alexander Korotkov wrote: > 1) Is it intended to switch all in-core libraries to use > PG_MODULE_MAGIC_EXT()? > 2) Once we have module version information, it looks natural to > specify the required version for dependant objects, e.g. SQL-funcions > implemented in shared libraries. For instance, > CREATE FUNCTION ... AS 'MODULE_PATHNAME' LANGUAGE C module_version >= '1.0'; > For this, and probably other purposes, it's desirable for version to > be something comparable at SQL level. Should we add some builtin > analogue of pg_text_semver?
I see that this is just a way for extensions to map to some data
statically stored in the modules themselves based on what I can see at
[1]. Why not.
+ bool isnull[3] = {0,0,0};
Could be a simpler {0}.
-PG_MODULE_MAGIC;
+PG_MODULE_MAGIC_EXT(
+ .name = "auto_explain",
+ .version = "1.0.0"
+);
It does not make sense to me to stick that into into of the contrib
modules officially supported just for the sake of the API. I'd
suggest to switch in one of the modules of src/test/modules/ that are
loaded with shared_preload_libraries. A second thing I would suggest
to check is a SQL call with a library loaded via SQL with a LOAD.
test_oat_hooks is already LOAD'ed in a couple of scripts, for example.
For the shared_preload_libraries can, you could choose anything to
prove your point with tests.
+Datum
+module_info(PG_FUNCTION_ARGS)
This should use a "pg_" prefix, should use a plural term as it is a
SRF returning information about all the modules loaded. Perhaps just
name it to pg_get_modules() and also map it to a new system view?
Some problems with `git diff --check\` showing up here.
No documentation provided.
[1]
https://www.postgresql.org/message-id/0e82bf8c-ae70-498d-861e-dba2bb154...@gmail.com
--
Michael
signature.asc
Description: PGP signature
