On Thu, Feb 3, 2011 at 12:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Florian Pflug <f...@phlo.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.
I think you can pretty much take it to the bank that there will be demand. This is an important, real-world problem. That having been said, I'm not 100% convinced that the main extensions patch is ready for prime-time, and I'm even less convinced that the upgrade patch is anywhere the point where we want to commit to it long-term. So I would have no qualms about punting it out to 9.2. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
