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
