Re: Extension Templates S03E11

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, 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-03 18:43:11
Message-ID: 1386096191.19125.165.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2013-12-03 at 09:20 -0500, Stephen Frost wrote:
> * Jeff Davis (pgsql(at)j-davis(dot)com) wrote:
> > Stephen mentioned using external tools and/or metadata, but to me that
> > sounds like it would require porting the extension away from what's on
> > PGXN today.
>
> Not at all- and that'd be the point. An external tool could take the
> PGXN extension, run 'make', then 'make install' (into a userland
> directory), extract out the script and then, with a little help from PG,
> run that script in "extension creation mode" via libpq.

What is stopping Extension Templates, as proposed, from being this
special "extension creation mode"? What would be a better design?

It seems like the porting issue is just a matter of finding someone to
write a tool to reliably translate packages from PGXN into a form
suitable to be sent using SQL commands; which we would need anyway for
this special mode.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-12-03 18:44:15 Why we are going to have to go DirectIO
Previous Message Andrew Gierth 2013-12-03 18:41:36 Re: WITHIN GROUP patch