public inbox for [email protected]
help / color / mirror / Atom feedFrom: David E. Wheeler <[email protected]>
To: PostgreSQL Hackers <[email protected]>
Cc: Gabriele Bartolini <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Christoph Berg <[email protected]>
Cc: Andres Freund <[email protected]>
Subject: Re: RFC: Extension Packaging & Lookup
Date: Thu, 31 Oct 2024 15:41:27 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Fellow Humans,
I’m working on an updated proposal with more detail, and more comprehensive. But I keep getting a bit caught up on this bit:
On Oct 28, 2024, at 18:19, David E. Wheeler <[email protected]> wrote:
>> * Binary-only extensions might also be installed here; the difference is they have no control file. The LOAD command and shared_preload_libraries would need to know to look here, too.
>
> Or perhaps we should require a control file for these, too, but add a “type” key or some such? Maybe such a shared module could be supported by CREATE EXTENSION, as well as, but not include SQL files?
I’m trying to imagine how this ought to work. The challenge is that, with the layout I propose here, shared module files will no longer always be in `$dynamic_library_path`, but in any `$extension/pkglib` subdirectory of each subdirectory of `extension_path`, as well. Is that desirable?
Let’s say we want to load a module named “semver” that’s included in the semver extension. With the proposed organization up-thread, the module would be installed in:
```
$extdir_user/semver/pkglib/semver.(so|dylib|dll|etc)
```
What should be passed to preload/LOAD to load it? A few options:
Option 1
--------
* Specify the module name “semver” in the `LOAD` command or in
`*_preload_libraries` (same as in 17 and earlier)
* Teach the preload/LOAD code to search for the module file in `*/pkglib/`
under each extension path
Pros:
* Follows the existing module name specification in preload/LOAD
Cons:
* Potentially huge number of directories to search, when lots of extension
are installed.
* Depending on search order, the wrong module may be loaded if two
extensions have a module file with the same name
Option 2
--------
* Specify the module name to include the extension name. Perhaps something
like `$extension:$module`.
* Teach the preload/LOAD code to detect the extension name as part of the
command and only look for the DSO in that extension's `pkglibdir`.
Pros:
* Searches at most the list of directories in the `extension_path`.
* No conflicts with any other module files from other extensions.
Cons:
* Overloads the meaning of preload/LOAD strings, which might be confusing to
some.
* Upgrades might need these values to change from the old to the new syntax.
Other Options?
--------------
I kind of like Option 2, as it would allow us to eventually support non-`CREATE EXTENSION` modules as extensions, too. I imagine distributing, say `auto_explain` in an extension directory of its own, with a `auto_explain.control` file that identifies it as a LOAD-only extension. Then specifying `auto_explain:auto_explain` would work as expected. Or perhaps just `auto_explain:` could load *all* the modules included in the auto_explain "extension".
But then maybe I'm starting to talk myself into arguing that `LOAD` ought to be deprecated, `CREATE EXTENSION` could support non-SQL extensions, and the `*preload*` GUCs would contain a list of extensions rather than module files.
But I digress. Any ideas about other options to address this design challenge?
Thanks,
David
view thread (8+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: RFC: Extension Packaging & Lookup
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox