Re: Dumping an Extension's Script - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Dumping an Extension's Script
Date
Msg-id CA+TgmoZF3iJ3c9GTfpwud4WFV2UMQtccbFAH5rKug3EsfJTzrA@mail.gmail.com
Whole thread Raw
In response to Re: Dumping an Extension's Script  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Dumping an Extension's Script  (Andres Freund <andres@2ndquadrant.com>)
Re: Dumping an Extension's Script  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
On Wed, Dec 5, 2012 at 12:47 PM, Andres Freund <andres@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: json accessors
Next
From: Robert Haas
Date:
Subject: Re: autovacuum truncate exclusive lock round two