Re: ALTER TABLE modifications - Mailing list pgsql-patches

From Hannu Krosing
Subject Re: ALTER TABLE modifications
Date
Msg-id 1068991799.17671.22.camel@fuji.krosing.net
Whole thread Raw
In response to ALTER TABLE modifications  (Rod Taylor <pg@rbt.ca>)
List pgsql-patches
Rod Taylor kirjutas L, 08.11.2003 kell 18:55:
> 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.

...

> 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.

Do you have special cases for type changes which don't need data
transforms.

I mean things like changing VARCHAR(10) to VARCHAR(20), dropping the NOT
NULL constraint or changing CHECK A < 3 to CHECK A < 4.

All these could be done with no data migration or extra checking.

So how much of it should PG attemt to detect automatically and should
there be NOSCAN option when progremmer knows better
(changing CHECK ABS(A) < 3 into CHECK 9 > (A*A) )

----------------
Hannu


pgsql-patches by date:

Previous
From: Manfred Spraul
Date:
Subject: SIGPIPE handling
Next
From: Bruce Momjian
Date:
Subject: Re: SIGPIPE handling