On 17/2/2025 04:00, Michael Paquier wrote:
> 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}.
Done
>
> -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
Done
> 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.
Done
>
> +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?
Sure, done.
>
> Some problems with `git diff --check\` showing up here.
Done
>
> No documentation provided.
Ok, I haven't been sure this idea has a chance to be committed. I will
introduce the docs in the next version.
--
regards, Andrei Lepikhov