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 g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
