Re: pg_dump --split patch

Joel Jacobson wrote:
> To understand a change to my database functions, I would start by 
> looking at the top-level, only focusing on the names of the functions 
> modified/added/removed.
> At this stage, you want as little information as possible about each 
> change, such as only the names of the functions.
> To do this, get a list of changes functions, you cannot compare two 
> full schema plain text dumps using diff, as it would only reveal the 
> lines changed, not the name of the functions, unless you are lucky to 
> get the name of the function within the (by default) 3 lines of copied 
> context.
>
> While you could increase the number of copied lines of context to a 
> value which would ensure you would see the name of the function in the 
> diff, that is not feasible if you want to quickly "get a picture" of 
> the code areas modified, since you would then need to read through 
> even more lines of diff output.

I can agree on some use cases you've outlined, where there's merit to 
the general idea of your patch.  But as an aside, you really should 
launch an investigation into some better diff tools if this is how 
you're doing this type of work.  Last week I reviewed 3K lines worth of 
changes from two versions of a 12K line schema dump I'd never seen 
before in a couple of hours using kdiff3.  I'd have killed myself before 
finishing if I had to do the same job with traditional diff as you're 
describing it here.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books