ALTER [ COLUMN ] column SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN }
ADD table_constraint
DROP CONSTRAINT constraint_name [ RESTRICT | CASCADE ]
+ DISABLE TRIGGER [ trigger_name | ALL | USER ]
+ ENABLE TRIGGER [ trigger_name | ALL | USER ]
CLUSTER ON index_name
SET WITHOUT CLUSTER
SET WITHOUT OIDS
+
+ DISABLE/ENABLE TRIGGER
+
+ These forms disable or enable trigger(s) belonging to the table.
+ A disabled trigger is still known to the system, but is not executed
+ when its triggering event occurs. For a deferred trigger, the enable
+ status is checked when the event occurs, not when the trigger function
+ is actually executed. One may disable or enable a single
+ trigger specified by name, or all triggers on the table, or only
+ user triggers (this option excludes triggers that are used to implement
+ foreign key constraints). Disabling or enabling constraint triggers
+ requires superuser privileges; it should be done with caution since
+ of course the integrity of the constraint cannot be guaranteed if the
+ triggers are not executed.
+
+
+
+
CLUSTER
You must own the table to use ALTER TABLE>.
To change the schema of a table, you must also have
CREATE privilege on the new schema.
- To alter the owner, the new owner must have
- CREATE privilege on the schema.
+ To alter the owner, you must also be a direct or indirect member of the new
+ owning role, and that role must have CREATE privilege on
+ the table's schema. (These restrictions enforce that altering the owner
+ doesn't do anything you couldn't do by dropping and recreating the table.
+ However, a superuser can alter ownership of any table anyway.)
+
+ trigger_name
+
+ Name of a single trigger to disable or enable.
+
+
+
+
+
+ ALL
+
+ Disable or enable all triggers belonging to the table.
+ (This requires superuser privilege if any of the triggers are for
+ foreign key constraints.)
+
+
+
+
+
+ USER
+
+ Disable or enable all triggers belonging to the table except for
+ foreign key constraint triggers.
+
+
+
+
index_name
instead marks them as independently defined rather than inherited.
+ The TRIGGER>, CLUSTER>, OWNER>,
+ and TABLESPACE> actions never recurse to descendant tables;
+ that is, they always act as though ONLY> were specified.
+ Adding a constraint can recurse only for CHECK> constraints.
+
+
Changing any part of a system catalog table is not permitted.