Re: Extension Templates S03E11

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extension Templates S03E11
Date: 2013-12-17 10:03:23
Message-ID: m2zjnzbxqs.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KONDO Mitsumasa 2013-12-17 11:50:06 Re: Optimize kernel readahead using buffer access strategy
Previous Message David Rowley 2013-12-17 09:51:26 Re: [PATCH] Negative Transition Aggregate Functions (WIP)