On Wed, Apr 12, 2017 at 06:59:32PM -0400, Robert Haas wrote: > On Wed, Apr 12, 2017 at 6:30 PM, Peter Eisentraut > > 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.
Is pg_upgrade the right place for an extension upgrade script? When pg_upgrade started creating an incremental-analyze script, people thought it should be more generic so it was moved to vacuumdb --analyze-in-stages. Seems we should do the same thing for the extension upgrade script. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
