Re: extensions are hitting the ceiling - Mailing list pgsql-hackers

From Eric Hanson
Subject Re: extensions are hitting the ceiling
Date
Msg-id CACA6kxijfpbLFnZ-UX0mm8EX27LQRnTOgKE=inU9w8zaGfKvxA@mail.gmail.com
Whole thread Raw
In response to Re: extensions are hitting the ceiling  (Eric Hanson <eric@aquameta.com>)
List pgsql-hackers
On Tue, Apr 16, 2019 at 4:47 AM Eric Hanson <eric@aquameta.com> wrote:
We would probably be wise to learn from what has gone (so I hear) terribly wrong with the Node / NPM packaging system (and I'm sure many before it), namely versioning.  What happens when two extensions require different versions of the same extension?  At a glance it almost seems unsolvable, given the constraint that an extension can only be installed once, and only at a single version.  I don't understand why that constraint exists though.

How about this:

1. Extension can be installed once *per-version*.
2. Each version of an extension that is installed is assigned by the system a unique, hidden schema (similar to temp table schemas) whose name doesn't matter because the extension user will never need to know it.
3. There exists a dynamic variable, like you proposed above, but it includes version number as well.  @DEPNAME_VERSION_schema@ perhaps.  This variable would resolve to the system-assigned schema name of the extension specified, at the version specified.
4. Since sprinkling ones code with version numbers is awful, there exists a way (which I haven't thought of) to set a kind of search_path-type setting which sets in the current scope the version number of the extension that should be dereferenced, so developers can still use @DEPNAME_schema@.

This would allow multiple versions of extensions to coexist, and it would solve the problem with two extensions wanting the same dependency in different places.

It's radical, but extensions are radically broken.  A critique of the above would be that extensions still have a single global namespace, so personally I don't think it even goes far enough.

Cheers,
Eric

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: New vacuum option to do only freezing
Next
From: Masahiko Sawada
Date:
Subject: Re: Calling pgstat_report_wait_end() before ereport(ERROR)