Ugh. Definitely an oversight. Don't suppose you want to think about pulling the name out of the DROP command ;-) ?
Yeah, I've already done it - it's ugleeey, but it works :P
I'm running out of time unfortunately, and I need to know from you whether I should go back to my work on making owner and acl TOC entries fully independent? All this means is that people restoring pre-7.5 binary dumps into 7.5 will not get the owner fixes... But people using the binary format to upgrade seems like a pretty rare case to me!
Hardly --- for instance, people using large objects have no other choice.
Yes they can - they can just use the 7.5 pg_dump to upgrade...
You can *not* change pg_restore in a way that will make it impossible for such people to restore their dumps (and no, I don't think it will fly to tell someone after the fact they should have used 7.5 pg_dump...)
I didn't say they won't work, I just said that they will not have a fix for the owner/acl issue - I'll just check the version of their binary dump and if it doesn't have independent acls and owners, I will just restore it using the old set session authorization method.
Maybe it's sufficient to have a backwards-compatibility mode in which the SET SESSION AUTH commands still get issued same-as-ever. In fact, you could just automatically do that if you see the archive version is too old to have ALTER OWNER support.
That's what I was suggesting :) Peter E wanted me to keep a set session auth mode around anyway for sql standard compatibilty - is that still a requirement (it doesn't seem hard to do). However...I think that if you ask 100 postgres users if they want to be able to restore their own backups, or have sql standard backups, I know which one 100 of them will choose :)
Actually, this brings up another point - people occasionally complain on the list that pg_dump is not considered important enough :( ie. Is there any good reason we cannot backport the entire new pg_dump to the 7.4 branch, and change the 3 small things that prevent its output restoring to 7.4. This is because there are many 7.4 users who cannot restore their own backups to 7.4 in an emergency, and have resorted to using CVS pg_dump and running sed scripts over it...
On the whole though, I think editing the DROP commands might be the best way. Are there any cases where that would actually not work?
There's a couple of tricks.
* Drop commands for TYPEs have 'CASCADE' on the end (has that always been true)
* I currently assume that the last two characters in a drop command are ; and \n. I'm not sure if this has always been the case. Maybe I should make it loop until it removes the trailing semi-colon.
* Do we no longer worry about the SCHEMA AUTHORIZATION clause? I might set it to keep being issued in 'sql standard mode', but otherwise we cannot use it in dumps any more.
* I have to special case VIEWS and SEQUENCES to use ALTER TABLE...OWNER TO
* On the second scan I'm not sure what to use as the comment above each owner and acl bit - I'll make it the same as the master object.
* On the second scan I have to hard-code the list of object types that need to have owners and acls dumped.
Other than that it works really well :) I just have to tie off some loose ends and make really sure that my drop command extraction is safe from buffer errors, etc. Hopefully I'll be able to submit tonight.
Chris
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
