Re: Extension Templates S03E11 - Mailing list pgsql-hackers

* Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
> > OTOH, for a set of pure-SQL objects, it's not necessary that there be a
> > canonical text file somewhere, and we have in principle complete knowledge
> > of the objects' semantics as well as the ability to dump-and-restore into
> > newer PG versions.  So it's not at all clear that we should just adopt the
> > existing model with the smallest possible changes --- which AFAICS is
> > basically what this proposal is.  Maybe that's the way to go, but we
> > should consider alternatives, and in particular I think there is much
> > more reason to allow inside-the-database mutation of the SQL objects.
>
> My thinking is that if we invent a new mechanism for extensions that are
> not managed like contribs, we will find out that only contribs are going
> to be using extensions.

That's only accurate if the new mechanism supports .so's, which seems
unlikely to be the case.  What I think we'd end up with is a split
between extensions, which would be things containing .so's, and
"libraries" or what-have-you, which would be more-or-less everything
else.  That kind of a break-down strikes me as perfectly reasonable.
There would also be flexability in that an author might choose to use an
extension even in cases where it's not strictly necessary to do so, for
whatever reason they want.

> Given the options of either growing extensions into being able to cope
> with more than a single model or building an entirely new system having
> most of the same feature set than Extensions, I'm pushing for the option
> where we build on top of what we have already.

I'm not sure that we need to throw away everything that exists to add on
this new capability; perhaps we can build a generic versioned
object-container system on which extensions and
packages/libraries/classes/whatever can also be built on (or perhaps
that's what 'extensions' end up morphing into).

> We can't use “package” because it means something very different in
> direct competition. I have other propositions, but they are only
> relevant if we choose not to improve Extensions… right?

I'd like to see extensions improved.  I don't feel like the proposed
'extension templates' is the way to do that because I don't think it
really solves anything and it adds a layer that strikes me as wholly
unnecessary.  I could see pulling in the control file contents as a
catalog, adding in dependency information which could be checked
against, perhaps hard vs. soft dependencies, and other things that make
sense to track for extensions-currently-installed into a given database.

However, as I understand it from the various discussions on this topic
outside of this list, the immediate concern is the need for a multi-OS
extension distribution network with support for binaries, .so's and
.dll's and whatever else, to make installing extensions easier for
developers on various platforms.  I'm all for someone building that and
dealing with the issues associated with that, but building a client for
it in core, either in a way where a backend would reach out and
download the files or accepting binary .so's through the frontend
protocol, isn't the first step in that and I very much doubt it would
ever make sense.
Thanks,
    Stephen