Re: extensions are hitting the ceiling

On Tue, Apr 16, 2019 at 4:47 AM Eric Hanson <eric(at)aquameta(dot)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(at)(dot)

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