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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
