John Gray <jgray@azuli.co.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
