On Wed, Apr 12, 2017 at 6:30 PM, Peter Eisentraut
<peter.eisentraut@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
