From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Dumping an Extension's Script |
Date: | 2012-12-05 18:50:27 |
Message-ID: | CA+TgmoZF3iJ3c9GTfpwud4WFV2UMQtccbFAH5rKug3EsfJTzrA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 5, 2012 at 12:47 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> For me it seems pretty natural to support dumping extension the way they
> got created. I.e. a plain CREATE EXTENSION ...; if the extension was
> preinstalled and some form that includes the extension source if you
> installed it via the connection.
>
> Extensions that were installed in some global manner *should* not be
> dumped with ones installed over the connection. E.g. dumping /contrib or
> packaged modules seems to be a bad idea to me.
>
> That would possibly be useful as a debugging tool, but I don't see much
> point besides that.
I agree with all of that.
What I can't quite figure out is - AIUI, extensions are a way of
bundling shared libraries with SQL scripts, and a way of managing the
dump and restore process. If you just have SQL, there's no bundling
to do, and if you reverse out the pg_dump changes (which is more or
less what's being proposed here), then what do you have left other
than the good feeling of being "part of an extension"? At that point,
it seems to me that you've gone to a lot of work to add a layer of
packaging that serves no real purpose.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-12-05 19:00:45 | Re: autovacuum truncate exclusive lock round two |
Previous Message | Josh Berkus | 2012-12-05 18:49:35 | Re: json accessors |