Re: pg_upgrade + Extensions
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade + Extensions |
Дата | |
Msg-id | 655.1441065504@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade + Extensions (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: pg_upgrade + Extensions
|
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > On 08/31/2015 07:32 PM, Bruce Momjian wrote: >> Still, I don't know how many people are doing this, but the right fix is >> to get the names of the modules that are superceeded and tell pg_upgrade >> to skip them. > I don't think this knowledge should be hardcoded in pg_upgrade. I could > see some point in a switch that would tell pg_upgrade a list of > extensions to ignore. That would not be terribly helpful for cases where the pg_upgrade call is embedded in some wrapper script or other. In any case, there is plenty of precedent for hard-coding knowledge about specific version updates into pg_upgrade. The question here is whether it's feasible to handle extensions that way. I think we could reasonably expect to know about cases where a formerly separate extension got integrated into core, but are there other cases where pg_upgrade would need to ignore an extension in the old database? regards, tom lane
В списке pgsql-hackers по дате отправления: