On Wed, 2002-04-03 at 09:39, Christopher Kings-Lynne wrote:
> Hi All,
> 
> With regards to the proposed command.c refactoring...
> 
..about which I should apologise as I stuck my head above the parapet
and then sat on my ideas (mixing metaphors a bit).

> I've done it by removing command.c and replacing it with
> 
> portal.c
> alter.c
> lock.c
> namespace.c
> 
> Is that a good idea?  Will it break too many outstanding patches?

The feedback I had was not to worry too much about that! However, my
scheme doesn't take account of some of the more recent changes -I had
envisaged a more radical division by "object manipulated". Here's my
current working draft (doesn't include material from the last couple of
weeks):

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

PortalCleanup        
PerformPortalFetch   
PerformPortalClose   
        Portal support functions move to portal.c

AlterTableAddColumn  
AlterTableAlterColumnDefault
drop_default
AlterTableAlterColumnFlags
                        
        These move to table.c. They share common code for permissions
        and recursion. Therefore, propose to create a short helper
        routine (AlterTableAlterColumnSetup) which checks permissions,
        existence of relation (and acquirtes lock on rel?). Also
        provide macros for recursion, to be used in form:

        RECURSE_OVER_CHILDREN(relid);
        AlterTableDoSomething(args);
        RECURSE_OVER_CHILDREN_END;


find_attribute_walker 
find_attribute_in_node
RemoveColumnReferences
AlterTableDropColumn 

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

AlterTableAddConstraint 
AlterTableDropConstraint
        
        Move to table.c These also use permissions and recursion code.

AlterTableOwner      
AlterTableCreateToastTable 
needs_toast_table
        All move to table.c. (Seems a bit more drastic than necessary
        to split AlterTableCreateToastTable and move
        needs_toast_table to access/heap/tuptoaster.c). 

LockTableCommand
        Move to lock.c


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

DefineRelation
RemoveRelation
TruncateRelation
MergeAttributes
change_varattnos_walker
change_varattnos_of_a_node
StoreCatalogInheritance
findAttrByName
setRelhassubclassInRelation
        
        All move to table.c


define.c
--------

case_translate_language_name
        
        Remove this one and refer to that in proclang.c

compute_return_type
compute_full_attributes
interpret_AS_clause
CreateFunction

        Move to function.c 

DefineOperator

        Move to operator.c

DefineAggregate

        Move to aggregate.c

DefineType

        Move to type.c

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

remove.c
--------

RemoveOperator

        To operator.c

SingleOpOperatorRemove
AttributeAndRelationRemove

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

RemoveType

        To type.c

RemoveFunction

        To function.c

RemoveAggregate

        To aggregate.c


rename.c
--------


renameatt
renamerel
ri_trigger_type
update_ri_trigger_args

        To table.c




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

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

Regards

John


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to