Re: Refactoring of command.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Refactoring of command.c
Date
Msg-id 20398.1014791837@sss.pgh.pa.us
Whole thread Raw
In response to Re: Refactoring of command.c  (John Gray <jgray@azuli.co.uk>)
List pgsql-hackers
John Gray <jgray@azuli.co.uk> writes:
> As I'm new to this kind of change, I assume that I'd just submit a
> normal context diff for this and rely on it not getting tangled up with
> any other patches to these files? Or is this *too* radical a reshuffle?

As far as mechanics go, the main problem is that you can't expect those
files to hold still while you contemplate what to do with them; there's
probably a commit every day or two that hits at least one.

Your sketch of what-goes-where is a good first cut for discussion.  Once
you've learned what you can at this level, I'd suggest preparing a much
more detailed sketch, at the per-routine level, and posting that for
discussion.  Once people are happy with that, you can coordinate making
the actual patch and passing it to one of the committers for immediate
application.

Once it does get down to the actual diff, I'd suggest a context diff
plus specific notes to the committer that "this patch adds files a,b,c
and removes files x,y,z".  The cvs adds and cvs removes are extra steps,
of course, so it's good to point them out to be sure they're not missed.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: eWeek Poll: Which database is most critical to your
Next
From: Hiroshi Inoue
Date:
Subject: Re: eWeek Poll: Which database is most critical to your