Re: ALTER EXTENSION UPGRADE, v3
От | Robert Haas |
---|---|
Тема | Re: ALTER EXTENSION UPGRADE, v3 |
Дата | |
Msg-id | AANLkTinSqTe_frYtFmVr651P1mrW9jX1JMMC7qy2_3JB@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER EXTENSION UPGRADE, v3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER EXTENSION UPGRADE, v3
|
Список | pgsql-hackers |
On Thu, Feb 3, 2011 at 12:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Florian Pflug <fgp@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
В списке pgsql-hackers по дате отправления: