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
sharedmodules), or LOAD or *_preload_libraries to load a shared module. I propose to add support for shared-module-only
extensionsto 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
conflictwith the exiting LOAD patterns, which in the final section of [1] I attempt to resolve by proposing a single
wayto manage *all* extensions, instead of the two separate patterns we have today.
Best,
David
[1]: https://justatheory.com/2024/11/rfc-extension-packaging-lookup/
