Re: Fixing pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing pg_dump
Date
Msg-id 16266.1088388548@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing pg_dump  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: Fixing pg_dump
List pgsql-hackers
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> 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.

Lack of testing.  Maybe after 7.5 has been out for a while, we'll have
enough trust in current pg_dump to think of doing that, but on the other
hand it would be somewhat moot at that point.  The main point though is
that 7.4 is supposed to be a *stable* branch, and dropping a rewritten
pg_dump that hasn't even been through beta yet into a stable branch is
Simply Not Done.

> * Drop commands for TYPEs have 'CASCADE' on the end (has that always 
> been true)

Yeek.  That's got to be a hangover from pre-dependency-chasing days.
Let's lose it in our current output, at least.

> * 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.

I'd go for "remove while the last char is either ; or \n"; should cover
all cases.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Fixing pg_dump
Next
From: Tom Lane
Date:
Subject: Re: Fixing pg_dump