Feedback-ID: i7c334307:Fastmail
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\))
Subject: Re: RFC: Extension Packaging & Lookup
From: "David E. Wheeler" <david@justatheory.com>
In-Reply-To: <0ADD494C-83D3-42DA-B2F6-E6E435181B3D@justatheory.com>
Date: Thu, 31 Oct 2024 16:12:44 -0400
Cc: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>,
 Peter Eisentraut <peter@eisentraut.org>,
 Christoph Berg <myon@debian.org>,
 Andres Freund <andres@anarazel.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <64BBC6FF-61A1-4EC7-BDCB-192D0232283F@justatheory.com>
References: <2CAD6FA7-DC25-48FC-80F2-8F203DECAE6A@justatheory.com>
 <0D3FE0EA-0E87-42BD-AB15-D3549BFD0F4C@justatheory.com>
 <0ADD494C-83D3-42DA-B2F6-E6E435181B3D@justatheory.com>
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Archived-At: <https://www.postgresql.org/message-id/64BBC6FF-61A1-4EC7-BDCB-192D0232283F%40justatheory.com>
Precedence: bulk

On Oct 31, 2024, at 15:41, David E. Wheeler <david@justatheory.com> =
wrote:

> Other Options?
> --------------
>=20
> 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".
>=20
> 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.
>=20
> 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=E2=80=A6

D