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/
