On Wed, 2002-04-03 at 16:52, Tom Lane wrote:
> John Gray <[EMAIL PROTECTED]> 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.c
prototype commands/command.h -> commands/portal.h
refer executor/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 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;
prototype commands/command.h -> commands/tablecmds.h
refer tcop/utility.c commands/cluster.c executor/execMain.c
LockTableCommand
Move to lockcmds.c
prototype commands/command.h -> commands/lockcmds.h
refer tcop/utility.c
CreateSchemaCommand
Move to schemacmds.c
prototype commands/command.h -> commands/schemacmds.h
refer tcop/utility.c
creatinh.c
----------
DefineRelation
RemoveRelation
TruncateRelation
MergeDomainAttributes
MergeAttributes
change_varattnos_walker
change_varattnos_of_a_node
StoreCatalogInheritance
findAttrByName
setRelhassubclassInRelation
All move to tablecmds.c
prototye commands/creatinh.h -> commands/tablecmds.h
refer commands/sequence.c commands/view.c tcop/utility.c
define.c
--------
case_translate_language_name
Remove this one and refer to that in proclang.c. If this file
becomes 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 is
coming 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, likely
incompatible 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.h
refer 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.
---------------------------(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
