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

On Fri, Jul 06, 2012 at 08:38:01PM -0700, Maciek Sakrejda wrote:
> >> 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

Yes, if both binary and non-binary restores should throw errors, I am
fine with that too.  Frankly, the filter we use now for extensions in
binary mode, FirstNormalObjectId, isn't sufficient because I think you
can modify the extension without changing its oid.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +