On Oct 31, 2024, at 15:41, David E. Wheeler <da...@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 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? 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
