Re: ALTER EXTENSION UPGRADE, v3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: 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 17:38:36
Message-ID: 24959.1296754716@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Florian Pflug <fgp(at)phlo(dot)org> writes:
> I fully agree. The extension infrastructure should provide basic support
> for upgrades, not every kind of bell and whistle one could possible think of.

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.

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
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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Browne 2011-02-03 17:44:23 Re: [HACKERS] Slow count(*) again...
Previous Message Robert Haas 2011-02-03 17:28:29 Re: [HACKERS] Slow count(*) again...