On Wed, Apr 12, 2017 at 6:30 PM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 4/10/17 11:30, Magnus Hagander wrote: >> After you've run pg_upgrade, you have to loop through all your databases >> and do an "ALTER EXTENSION abc UPDATE" once for each extension. >> >> Is there a reason we shouldn't have pg_upgrade emit a script that does >> this, similar to how it emits a script to run ANALYZE? > > Shouldn't pg_dump do this, and perhaps by default? > > If I restore a dump into another instance, I need to upgrade all my > extensions to that installations's versions, no? That's not particular > to pg_upgrade.
No, it's an optional step. If we did the upgrade by default, it would greatly increase the chance of something failing. For example, suppose the upgrade does a DROP and then CREATE of a function whose signature has changed. If there's anything that depends on that function, this will fail. But if we don't do it, there's no actual problem: the shared library is supposed to be prepared to cope with people still using the old SQL definition. It is probably desirable to update where possible to gain access to new features, etc., but it shouldn't be required. I do think there might be some value in a tool that looked for old extensions and tried to update them, but I'm not sure it should be pg_dump. -- 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
