Re: Extension Templates S03E11 - Mailing list pgsql-hackers

* Jeff Davis (pgsql@j-davis.com) wrote:
> On Wed, 2013-12-04 at 14:54 -0500, Tom Lane wrote:
> > I think Stephen has already argued why it could be a good idea here.
> > But in a nutshell: it seems like there are two use-cases to be
> > supported, one where you want "CREATE EXTENSION hstore" to give you
> > some appropriate version of hstore, and one where you want to restore
> > exactly what you had on the previous installation.  It seems to me that
> > "exploding" the extension by dumping, rather than suppressing, its
> > component objects is by far the most reliable way of accomplishing the
> > latter.
>
> The behavior of an extension should not depend on how it was installed.
>
> The kind of "extension" being described by Stephen will:
>
> * Not be updatable by doing "ALTER EXTENSION foo UPDATE TO '2.0'"

That's correct, but consider when the above command actually works
today: when the new version is magically made available to the backend
without any action happening in PG.  That works when the filesystem can
be updated independently or the backend can reach out to some other
place and pull things down but that's, really, a pretty special
situation.  It works today specifically because we expect the OS
packaging system to make changes to the filesystem for us but this whole
'extension template' proposal is about getting away from the filesystem.

Instead, I'm suggesting an external tool which can pull down the new
version from an external repo and then apply it to the backend.
Clearly, my approach supports the general action of updating an
extension, it just doesn't expect the filesystem on the server to be
changed underneath PG nor that PG will reach out to some external
repository on the basis of a non-superuser request to get the update
script.

> * Dump out objects that wouldn't be dumped if they had installed the
> extension using the filesystem

Correct, but the general presumption here is that many of these
"extensions" wouldn't even be available for installation on the
filesystem anyway.

> So if we do it this way, then we should pick a new name, like "package".

I've been on the fence about this for a while.  There's definitely pros
and cons to consider but it would go very much against one of the goals
here, which is to avoid asking extension authors (or their users, to
some extent..) to change and I expect it'd also be a lot more work to
invent something which is 90% the same as extensions.  Perhaps there's
no help for it and we'll need "extensions" which are essentially for
OS managed extensions (which can include .so files and friends) and then
"packages" for entirely-in-catalog sets of objects with a certain amount
of metadata included (version and the like).

> And then we'll need to decide whether it still makes sense to use an
> external tool to transform a PGXN extension into a form that could be
> loaded as a package.

I'd certainly think it would be but if we're moving away from calling
them extensions then I'm afraid extension authors and users would end up
having to change something anyway, no matter the tool.  Perhaps that's
reasonable and we can at least minimize the impact but much of what
extensions offer are, in fact, what's also needed for packages and I'm
not thrilled with the apparent duplication.

It just occured to me that perhaps we can "call" these something
different towards the end user but use the existing catalogs and code
for extensions to handle our representation, with a few minor tweaks..
Not sure if I like that idea, but it's a thought.
Thanks,
    Stephen