Re: Add Postgres module info

On Mon, Dec 23, 2024, at 8:49 PM, Andrei Lepikhov wrote:

> Looking into the control file, I see that most parameters are 
> unnecessary for the library. Why do we have to maintain this file?

Most of the parameters apply to SQL extensions.

> 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.

Well, either way you have to load the extension, either CREATE EXTENSION to load an SQL extension (and any related shared modules), or LOAD or *_preload_libraries to load a shared module. I propose to add support for shared-module-only extensions to CREATE/UPDATE/DROP EXTENSION. It would then both insert the version info in the database (from the control file, at least), and load the shares module(s).

> It would be interesting to read about your real-life cases that caused 
> your proposal.

They're in the first section of [1]. The desire to group all the files for an extension in a single directory led to a conflict with the exiting LOAD patterns, which in the final section of [1] I attempt to resolve by proposing a single way to manage *all* extensions, instead of the two separate patterns we have today.

Best,

David

[1]: https://justatheory.com/2024/11/rfc-extension-packaging-lookup/