Re: ALTER EXTENSION UPGRADE, v3
От | Tom Lane |
---|---|
Тема | Re: ALTER EXTENSION UPGRADE, v3 |
Дата | |
Msg-id | 24959.1296754716@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ALTER EXTENSION UPGRADE, v3 (Florian Pflug <fgp@phlo.org>) |
Ответы |
Re: ALTER EXTENSION UPGRADE, v3
Re: ALTER EXTENSION UPGRADE, v3 Re: ALTER EXTENSION UPGRADE, v3 |
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: