ALTER TABLE modifications

A general re-organization of Alter Table. Node wise, it is a
AlterTableStmt with a list of AlterTableCmds.  The Cmds are the
individual actions to be completed (Add constraint, drop constraint, add
column, etc.)

Processing is done in 2 phases. The first phase updates the system
catalogs and creates a work queue for the table scan. The second phase
is to conduct the actual table scan evaluating all constraints and other
per tuple processing simultaneously, as required. This has no effect on
single step operations, but has a large benefit for combinational logic
where multiple table scans would otherwise be required.

Steps for the table scan include expression processing (default or
transform expressions), not null constraint process, other constraints.


The code has been simplified a little. Simple permission and recursion
checks are conducted in the common area and an enum for the command type
is used rather than a Char.


ALTER TABLE ADD COLUMN col DEFAULT 3 NOT NULL;
        Allow creation of a column with a default (filled) and not null
        constraint. This is internally subdivided into 3 actions much
        like the below syntax.

ALTER TABLE tab ADD COLUMN col DEFAULT 3, ADD CHECK (anothercol > 3);
        The above combinational syntax is commented out in gram.y. The
        support framework is used in both the above and below items, but
        arbitrary statements probably have some issues -- I've not
        tested enough to determine.

        If it is useful, it will be submitted at a later date.

ALTER TABLE tab ALTER COLUMN col TYPE text TRANSFORM ...;
        Currently migrates indexes, check constraints, defaults, and the
        column definition to the new type with optional transform. If
        the tranform is not supplied, a standard assignment cast is
        attempted.

        One issue is that it detects dependencies way too late in the
        game (after the TRANFORM has been applied). I tried mucking up
        performDeletion to have a RESTRICT that did not throw the error
        at the end (or physically remove the items) but that didn't work
        out. Any bright ideas on how to achieve the NOTICES from a
        failed DROP COLUMN earlier? Otherwise, I can put in single
        object detection at that point.

        It does not migrate foreign keys yet (should be easy to add) and
        will be forwarded as an independent patch at a later time.
        Currently foreign keys are rejected like views, functions, etc.


Comments appreciated.
--
Rod Taylor <pg [at] rbt [dot] ca>

Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL