Re: command.c breakup

John Gray <jgray(at)azuli(dot)co(dot)uk> writes:
> Here's my current working draft (doesn't include material from the
> last couple of weeks):

Please note that there's been pretty substantial revisions in command.c
and creatinh.c over the past couple of weeks for schema support. While
I think that those two files are largely done with, define.c and
remove.c are about to get the same treatment as the schema project moves
on to schema-tizing functions and operators. So we'll need to coordinate
just when and how to make these structural revisions; and you'll
definitely need to be working against CVS tip. What are your plans,
time-wise? Does it make sense for the two of you to work together?

> These are part of the old DROP_COLUMN_HACK. Should they go in
> the transfer? (There seems to be agreement that DROP COLUMN
> will not be implemented as it is here).

I think Hiroshi finally removed all the DROP_COLUMN_HACK code yesterday.

> Parameter fetching support, generic to all the processing for
> define statements. Inclined to move to type.c as used most by type
> creation.

What about leaving define.c in existence, but have it hold only common
support routines for object-definition commands? The param fetchers
would certainly fit in this category, and maybe some of the other
support routines you've described would fit here too.

> To operator.c (or delete altogether -NOTYET since 94!)

NOTYET probably means NEVER; whenever that functionality is implemented,
it'll be based on some sort of generic dependency code, not
special-purpose checks. Feel free to remove this stuff too.

> Thus, the change in the set of files:

> Removed:

> command.c
> creatinh.c
> define.c
> remove.c
> rename.c

> Added:
> aggregate.c
> function.c
> operator.c
> table.c
> type.c

Minor gripe here: I would suggest taking a cue from indexcmds.c and
choosing file names along the lines of functioncmds.c, tablecmds.c,
etc. The above names strike me as too generic and likely to cause
confusion with similarly-named files in other directories.

> Sorry for going slow on this - but it seems that the organisation
> has dropped out of my life in the last few weeks :) (and I've been away
> over Easter).

Not a problem. But we'll need a concentrated burst of work whenever
you are ready to prepare the final version of the patch; otherwise the
synchronization issues will cause problems/delays for other people.

regards, tom lane