Re: Add Postgres module info

On 12/24/24 02:23, David E. Wheeler wrote:
> On Dec 11, 2024, at 19:49, Euler Taveira <euler@eulerto.com> wrote:
> 
>>> FWIW, Id like to have some more information in there, without commenting on
>>> the specifics.
>>
>> +1 for the general idea.
> 
> Same.
> 
>> I received some reports like [1] related to wal2json
>> that people wants to obtain the output plugin version. Since it is not installed
>> via CREATE EXTENSION, it is not possible to detect what version is installed,
>> hence, some tools cannot have some logic to probe the module version.
> 
> I’m all for additional metadata for native extensions, but I’d also like to draw attention to the “Future” section my proposal[1] to require that module-only extensions also include a control file and be loadable via CREATE EXTENSION (and proposed *_preload_extensions GUCs[2]). This would unify how all types of extensions are added to a database, and would include version information as for all other CREATE EXTENSION extensions.
Looking into the control file, I see that most parameters are 
unnecessary for the library. Why do we have to maintain this file?
In my experience, extra features are usually designed as shared 
libraries to 1) reduce complexity, 2) work across the overall cluster, 
3) be dynamically loaded, 4) be hidden, and not waste the database with 
any type of object. - remember, applications sometimes manage their data 
through an API; databases and any objects inside may be created/moved 
automatically, and we want to work in any database.
The 'CREATE EXTENSION' statement would have made sense if we had 
register/unregister hook machinery. Without that, it seems it is just 
about maintaining the library's version and comments locally in a 
specific database.
It would be interesting to read about your real-life cases that caused 
your proposal.

-- 
regards, Andrei Lepikhov