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/
