Re: command.c breakup - Mailing list pgsql-hackers

On Wed, 2002-04-03 at 16:52, Tom Lane wrote:
> 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?
> 
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'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.

As far as joint working goes, if Chris K-L would like to grab all or
part of it he is very welcome :) My timescale is that I have time at
present to work on it, so maybe next week for incorporation (but do
people need more notice than that?)

Obviously, I haven't given more details of the common code elimination.
That is a slightly different kind of task -I'll post some specifics on
that in the next couple of days.

> >     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.
>
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? 

> >     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.
> 

OK

> > Thus, the change in the set of files:
> 
> 
> 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.
> 
Yes, this makes sense and I've done that too.


> > 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.
> 

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).

Regards

John



src/backend/commands/ directory reorganisation version 2 
(including dependencies), from CVS as of 12 noon, 2002-04-11)

Dependencies were determined from LXR cross-reference database. This
will show all *usage* -it won't catch cases where a header file is included
redundantly. Recursive grep seems to provide the same answers though.

command.c
---------

PortalCleanup        
PerformPortalFetch   
PerformPortalClose   Portal support functions move to portalcmds.cprototype commands/command.h ->
commands/portal.hreferexecutor/spi.c tcop/pquery.c tcop/utility.c
 


AlterTableAddColumn  
AlterTableAlterColumnDropNotNull
AlterTableAlterColumnSetNotNull
AlterTableAlterColumnDefault
drop_default
AlterTableAlterColumnFlags
AlterTableDropColumn             
AlterTableAddConstraint 
AlterTableDropConstraint
AlterTableOwner      
AlterTableCreateToastTable 
needs_toast_table
These move to tablecmds.c. They share common code for permissionsand recursion. Therefore, propose to create a short
helperroutine(AlterTableAlterColumnSetup) which checks permissions,existence of relation (and acquirtes lock on rel?).
Alsoprovidemacros for recursion, to be used in form:
 
RECURSE_OVER_CHILDREN(relid);AlterTableDoSomething(args);RECURSE_OVER_CHILDREN_END;
prototype commands/command.h -> commands/tablecmds.hrefer tcop/utility.c commands/cluster.c executor/execMain.c


LockTableCommandMove to lockcmds.c
prototype commands/command.h -> commands/lockcmds.hrefer tcop/utility.c

CreateSchemaCommandMove to schemacmds.c
prototype commands/command.h -> commands/schemacmds.hrefer tcop/utility.c

creatinh.c
----------

DefineRelation 
RemoveRelation 
TruncateRelation 
MergeDomainAttributes
MergeAttributes
change_varattnos_walker
change_varattnos_of_a_node
StoreCatalogInheritance
findAttrByName
setRelhassubclassInRelationAll move to tablecmds.c
prototye commands/creatinh.h -> commands/tablecmds.hrefer commands/sequence.c commands/view.c tcop/utility.c

define.c
--------

case_translate_language_nameRemove this one and refer to that in proclang.c. If this filebecomes a file for support
functions,then the reverse should apply.
 

compute_return_type
compute_full_attributes
interpret_AS_clause
CreateFunction
Move to functioncmds.c 
prototype commands/defrem.h -> ?refer tcop/utility.c

DefineOperator
Move to operatorcmds.c
prototype commands/defrem.h -> ?refer tcop/utility.c


DefineAggregate
Move to aggregatecmds.c
prototype commands/defrem.h -> ?refer tcop/utility.c


DefineDomain
Move to domaincmds.c
prototype commands/defrem.h -> ?refer tcop/utility.c


DefineType
Move to typecmds.c
prototype commands/defrem.h -> ?refer tcop/utility.c

findTypeIOFunction
defGetString
defGetNumeric
defGetQualifiedName
defGetTypeName
defGetTypeLength
Keep in define.c as general support code. If other support code iscoming here to, there might be a good case for a new
file"cmdutils.c",say, to hold all sorts of generic code for permissions,recursion, etc.
 

remove.c
--------

RemoveOperator
To operatorcmds.c

SingleOpOperatorRemove
AttributeAndRelationRemove
Propose to delete altogether -NOTYET since 94, likelyincompatible with current workings)

RemoveType
To typecmds.c

RemoveDomain
To domaincmds.c

RemoveFunction
To functioncmds.c

RemoveAggregate
To aggregatecmds.c

prototypes and dependencies for these identical to Define commands in define.c


rename.c
--------

renameatt
renamerel
ri_trigger_type
update_ri_trigger_args
To tablecmds.c
prototype commands/rename.h -> commands/tablecmds.hrefer tcop/utility.c commands/cluster.c


Thus, the change in the set of files:

Removed:

command.c
creatinh.c
remove.c
rename.c

(and include files commands/command.h, commands/creatinh.h, commands/rename.h)


Added:
aggregatecmds.c
functioncmds.c
operatorcmds.c
portalcmds.c
tablecmds.c
typecmds.c
lockcmds.c
schemacmds.c

(and include files commands/portalcmds.h, commands/lockcmds.h, 
commands/tablecmds.h, commands/schemacmds.h)

Possibly "rename"[*] residual define.c to cmdsupport.c (and create new
header file commands/cmdsupport.h) which would also hold common 
permissions checkiing and inheritance code.