| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, 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-04 22:07:03 |
| Message-ID: | 529FA787.60004@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/2/13, 9:14 AM, Dimitri Fontaine wrote:
> What I want to build is an “extension distribution” software that knows
> how to prepare anything from PGXN (and other places) so that it's fully
> ready for being used in the database. Then the main client would run as
> a CREATE EXTENSION "ddl_command_start" Event Trigger and would fetch the
> prepared extension for you and make it available, then leaving the main
> command operate as intended.
>
> Which is what I think the pex extension is doing, and that's not
> coincidental, but it runs the build step on the PostgreSQL server itself
> and needs to have a non-trivial set of file-system privileges to be
> doing so, and even needs to get root privileges with sudo for some of
> its operations.
You're thinking of autopex, and while that works, and can be made to
work better with certain small changes, I don't think it can ever be the
only solution. Many interesting extensions will have external packages
build and run-time dependencies, and you need file-system level access
to manage that.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2013-12-04 22:12:29 | Re: Extension Templates S03E11 |
| Previous Message | Tom Lane | 2013-12-04 22:01:27 | Re: WITHIN GROUP patch |