Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created

>> Well, the part I understood was that your fix apparently does not
>> guarantee to restore plpgsql to the state it was in, just to restore
>> it to existence. But previous complaints about similar issues have
>> fallen on deaf ears (see bug #5184). Perhaps Tom has had a change of
>> heart, but if so we have a few things to fix, not just this one.
>
> Yes, I think my fix gives binary-upgrade the same behavior as
> pg_dump/restore --- for all its good and bad. I couldn't see why they
> should be different, or at least why binary-upgrade should be worse
> (throw an error).

I agree that they shouldn't be different, but if this can't be made to
work, perhaps both should fail in this situation? Changing ownership
of objects on a dump/restore seems like a decidedly un-Postgres-like
foot-gun. Granted, this is only applicable in only a small set of
situations, but it's still a foot-gun--a metadata integrity issue if
you will. For what it's worth, I completely agree with Robert's
comments in the thread regarding #5184 [1]. Does the comparison to
template0/1 suggested in that thread merit further consideration?

[1]: http://archives.postgresql.org/pgsql-bugs/2009-11/msg00113.php