Skip site navigation (1) Skip section navigation (2)

Re: ALTER EXTENSION UPGRADE, v3

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER EXTENSION UPGRADE, v3
Date: 2011-02-03 18:21:34
Message-ID: m262t16ksx.fsf@2ndQuadrant.fr (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Maybe somewhere around here we should stop and ask why we are bothering
> with any of this.  The original idea for an extension concept was that
> (1) some collection of objects could be designated as a module
> (2) pg_dump would be taught to dump "LOAD MODULE foo" instead of the
> individual objects
> (3) the way you'd do an upgrade is to dump and reload into a database
> that has available a newer definition of the module's content.

That upgrade solution is fine in some cases for major upgrades.  That's
not what we're talking about here, though.  Extension release schedule
is to be quite different from PostgreSQL one.

> Given that pg_upgrade is now considered a supported piece of the system,
> ISTM that most real-world upgrade scenarios will be accomplished with
> pg_upgrade relying on provision (3).  It looks to me like we're talking
> about adding a large amount of complication --- both for the core
> database and for module authors --- in order to provide a duplicate
> solution for that.  Why should we bother?  Especially, why should we

Think in particular about in-house extensions: a collection of PL code
that's not maintained in the database but in some SCM, typically.
You keep maintaining your application, and the PL code too, and you keep
wanting to roll out those changes to production.  Having a way to
package that then ALTER EXTENSION myappplcode UPGRADE; sounds nice to
me.  Nothing to do with PostgreSQL upgrades, though, really.

> bother in version 1 of the feature?  This could all be added later if
> we determine there's really sufficient demand, but right now we have
> no experience to show whether there is demand or not.

The reason why I've been bothering for version 1 is so that we can
support people upgrading from a previous version of PostgreSQL with
extensions installed, and who will want that both \dx and pg_dump
behaves correctly from day-1 in 9.1.

We will need to bootstrap the process some day, first extension enabled
release sounded fine from here.  Nobody will want to DROP TYPE hstore
CASCADE; then repair, all just so that they'll able to have a better
pg_dump next time.

Now, current patch to do that is rather small if you don't include the
new contrib scripts.  First line is src only, second one src+doc:

 22 files changed, 946 insertions(+), 69 deletions(-)
 40 files changed, 1352 insertions(+), 79 deletions(-)

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-02-03 18:24:47
Subject: Re: arrays as pl/perl input arguments [PATCH]
Previous:From: Andrew DunstanDate: 2011-02-03 18:20:48
Subject: Re: arrays as pl/perl input arguments [PATCH]

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group