On Oct 31, 2024, at 15:41, David E. Wheeler <david@justatheory.com> wrote:
> 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
thatidentifies it as a LOAD-only extension. Then specifying `auto_explain:auto_explain` would work as expected. Or
perhapsjust `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
supportnon-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?
I just thought of another one:
Option 3
--------
* Add a new preload GUCs for extensions: `shared_preload_extensions`,
`session_preload_extensions`, etc.
* Specify just extension names for these GUCs, instead of module file names.
* Leave `LOAD/*preload_libraries` unchanged.
* Have it search the `extension_path` directories just as `CREATE EXTENSION`
does.
Pros:
* The behaviors of `LOAD/*preload_libraries` are unchanged
* Provide a more future-looking interface, where we perhaps eventually
deprecate `LOAD/*preload_libraries` in favor of shipping all modules as
extensions.
Cons:
* More GUCs!
* The new GUCs load *all* of the modules included in an extension, rather
than specific ones. But maybe we can borrow the `$extension:module` syntax
from Option 2 to support loading a single extension
* Upgrades from Postgres 17 would still need any extension modules loaded
in `*preload_libraries` moved to the new GUCs, since the files will live
in a new location
I kind of like this one…
D
