From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Sergey Muraviov <sergey(dot)k(dot)muraviov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: extension_control_path |
Date: | 2014-03-10 08:36:14 |
Message-ID: | m238iq1mdd.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Aside from those details, it seems clear that any reasonably complete
> move-extensions-elsewhere feature will need some kind of build system
> support. I have various ideas on that and would gladly contribute some
> of them, but it's not going to happen within two weeks.
+1
Note that I am currently working on such a build system, so feel free to
send me off-list emails about your thoughs, I'm interested and could
integrate them into what I'm building.
> At this point I suggest that we work toward the minimum viable product:
> the extension_control_path feature as originally proposed (plus the
> crash fixes), and let the field work out best practices. As you
> describe, you can work around all the other issues by patching various
> text files, but you currently cannot move the extension control file in
> any way, and that's a real deficiency. (I once experimented with bind
> mounts to work around that -- a real mess ;-) )
Please find attached the v2 version of the patch, including fixes for
the crash and documentation aspects you've listed before.
Regards,
--
Dimitri Fontaine 06 63 07 10 78
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachment | Content-Type | Size |
---|---|---|
extension_control_path.v2.patch | text/x-patch | 29.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | MauMau | 2014-03-10 09:09:00 | Re: [bug fix] pg_ctl always uses the same event source |
Previous Message | Kyotaro HORIGUCHI | 2014-03-10 08:29:11 | Re: inherit support for foreign tables |