Re: command.c breakup

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

In response to

Responses

Browse pgsql-hackers by date

  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