public inbox for [email protected]  

help / color / mirror / Atom feed

From: 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 16:12:44 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>

On Oct 31, 2024, at 15:41, David E. Wheeler <[email protected]> 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

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