From: | John Gray <jgray(at)azuli(dot)co(dot)uk> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: command.c breakup |
Date: | 2002-04-03 09:10:22 |
Message-ID: | 1017825025.1367.6.camel@adzuki |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2002-04-03 14:20:11 | Question: update and transaction isolation |
Previous Message | Christopher Kings-Lynne | 2002-04-03 08:39:39 | command.c breakup |