Re: Extension Templates S03E11

Tom Lane <tgl@sss.pgh.pa.us> writes:
> Right.  I think a lot of the tension comes from people being unconvinced
> that the existing extension feature is an ideal model for this sort of
> use-case.  Extensions were mainly designed around the notion of a .so

The effort here is all about extending the Extension Use Case, yes.

> 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.

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 think the name "Extension Templates" is horrible because it misleads
>> all of us on this list into thinking the proposed feature is completely
>> something other than what it is.  I don't have a better name offhand,
>> but that's got to change before it becomes a feature.
>
> Given your previous para, I wonder if "library" or "package" would work
> better.  I agree that "template" isn't le mot juste.

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?

Regards,
--
Dimitri Fontaine                                        06 63 07 10 78
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support