Re: Fixing pg_dump

> 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