Re: Extension Templates S03E11

* Dimitri Fontaine (dimitri(at)2ndQuadrant(dot)fr) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > I'm not convinced we really need to solve that problem, but one way to
> > solve it 'cleanly' would be to seperate the two types of extensions,
> > perhaps by calling them by different names or inventing a namespace for
> > extensions.
>
> My understanding is that this line of thoughts gave us Extension
> Templates which are templates, not extensions.

Errr. "Extension Templates" aren't collections of objects in the
database which can be used directly by users. That's what extensions
are, except that they have to currently be installed from files on the
filesystem.

> > I think we're falling into the trap of thinking that whatever this
> > user-installable-collection-of-objects thing is, it must be considered
> > PG 'extensions'. While I agree that some of the things we do for
> > extensions should also be done with these collections of objects (eg:
> > having versions and other meta-data for them), I'm starting to think
> > that's the "small" side of this whole equation and duplicating that
> > meta-data store for these collections would be easier than trying to
> > shoehorn them into the existing notion of 'extensions'.
>
> My main question when thinking that way is:
>
> - how to update from a version to another one?

You pull down the new "collection-of-objects" pgxn module (or whatever)
and find the script that says "go from X.Y to Y.Z" and then run it, and
it runs the necessary add-to-collection/remove-from-collection magic
through libpq. Note that there would be a tool to do this, of course..
But my point is that it'd be a *client-side* tool, not something which
the backend does by reaching out to the internet and downloading files.

> The point about extensions is that we separate the author who maintains
> the upgrade scripts from the DBA who operates the upgrades. It seems to
> me it's important to keep that property.

I agree.

Thanks,

Stephen