Re: Add Postgres module info

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