Re: Dumping an Extension's Script

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(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 19:01:57
Message-ID: 20121205190157.GJ27424@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2012-12-05 13:50:27 -0500, Robert Haas wrote:
> 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.

Manageability.

E.g. for years I had a set of (trigger) functions to counted the number
of rows in a table in a lockless manner. That's used in 10+ applications
of former clients of mine. All (plpg)sql.
Imagine I want to ship an updated version that 1. removes some
*internal* functions, 2. adds some internal function. 3. adds a new
*external* function.

Now most of the clients use completely different development models and
completely different ways of manageing upgrades. I needed to integrate
my teensy module into all of them.

If we had a way to package it nicely they could just upload the
extension inside their own workflows and I (or they) would be freed from
integrating foreign update scripts into their workflow.

Imagine embedding a PGXN module into your application which is used on
many servers and doesn't need superuser privileges or anything. Same
thing.

That's not something all that uncommon is it?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2012-12-05 19:08:42 Re: PITR potentially broken in 9.2
Previous Message Robert Haas 2012-12-05 19:00:45 Re: autovacuum truncate exclusive lock round two