Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Hiroshi InoueDate: 2002-02-27 06:44:17
Subject: Re: eWeek Poll: Which database is most critical to your
Previous:From: Neil ConwayDate: 2002-02-27 06:21:44
Subject: Re: eWeek Poll: Which database is most critical to your

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group