Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers