Re: Refactoring of command.c

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

In response to

Browse pgsql-hackers by date

  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