Re: Dumping an Extension's Script

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

In response to

Responses

Browse pgsql-hackers by date

  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