From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Gray <jgray(at)azuli(dot)co(dot)uk> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Refactoring of command.c |
Date: | 2002-02-27 06:37:17 |
Message-ID: | 20398.1014791837@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
John Gray <jgray(at)azuli(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2002-02-27 06:44:17 | Re: eWeek Poll: Which database is most critical to your |
Previous Message | Neil Conway | 2002-02-27 06:21:44 | Re: eWeek Poll: Which database is most critical to your |