Re: command.c breakup

John Gray <jgray(at)azuli(dot)co(dot)uk> writes:
> I have compiled a new version against current CVS, now also including
> references to dependencies (See below). I accept that we'll need to work
> round the schema project -in the week since the last message I notice
> that namespace support has arrived for function, aggregate and operator
> creation. Is there more to come in these files?

I am hoping to commit the revisions for aggregates today. Operators are
still to come, and after that it's the mop-up stuff like rules ...

> I'm unsure whether it is sensible to split the commands/defrem.h file to
> match the actual .c files (given that there are at present only two
> externally referenced functions from each entity it seems reasonable to
> keep them together -as they are all referred to from tcop/utility.c
> anyway.

Probably can leave well enough alone there; I don't see what it would
buy us to split up that header file.

>> 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.
>>
> Yes, this seems sensible -but as far as the other support code goes, it
> might make sense to have a file called (say) cmdsupport.c where the
> parameter fetchers, the checking and recursion code etc. all goes?

If you prefer --- I haven't a strong feeling one way or the other.

> That shouldn't be too much of a problem in the next couple of weeks - if
> we can decide on a specific day I'll book it into my diary (Any day but
> Wednesday next week would be fine for me).

I will try to have no uncommitted changes over this weekend; that will
give you a clear field Monday morning, or you can start on the weekend
if you like. Sound good?

regards, tom lane