I thought I should just raise a couple of points -I think I may have
been the person Tom Lane was referring with respect to refactoring
command.c. I am still happy to go through and do this, though I think
that Neil Conway may be active there at present.
1) Division between files.
I imagined that the ALTER TABLE would move to alter.c (but maybe this
should be altertable.c?), the portal support would live in portal.c and
I wasn't sure where LOCK TABLE would go. If we're going to have a
command for showing current locks (I seem to remember that from some
time back, maybe it would go there too?)
2) Permissions checking and inheritance.
Much of the permissions checking and setup on the alter table variants
is the same. In my original patch I'd extracted this into a helper
routine. Also, all the commands which support inheritance do so using a
piece of boilerplate code -I had thought this could become a pair of
macros, either side of whatever action was to be performed on the
descendant.
3) ALTER TABLE CREATE TOAST TABLE
I don't see any need for this in the grammar! AlterTableAddColumn calls
it after a catalogue change, it is called (from ProcessUtility
tcop/utility.c) for CREATE TABLE, and InitPlan calls it for SELECT INTO.
I can't see any useful circumstance in which the command could be
issued, which makes it seem a good candidate for removal from the
grammar.
Any comments on these?
John
