Change the rules for inherited CHECK constraints to be essentially the same

as those for inherited columns; that is, it's no longer allowed for a child
table to not have a check constraint matching one that exists on a parent.
This satisfies the principle of least surprise (rows selected from the parent
will always appear to meet its check constraints) and eliminates some
longstanding bogosity in pg_dump, which formerly had to guess about whether
check constraints were really inherited or not.

The implementation involves adding conislocal and coninhcount columns to
pg_constraint (paralleling attislocal and attinhcount in pg_attribute)
and refactoring various ALTER TABLE actions to be more like those for
columns.

Alex Hunsaker, Nikhil Sontakke, Tom Lane

diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index f43c46908c0add7622ed37b56fc3f64ecf000e7d..d0b34789cf157ada1bc7f7929122956915503fa5 100644 (file)
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -1,4 +1,4 @@
-
+
 
@@ -1907,6 +1907,26 @@
       Foreign key match type
      
 
+     
+      conislocal
+      bool
+      
+      
+       This constraint is defined locally in the relation.  Note that a
+       constraint can be locally defined and inherited simultaneously
+      
+     
+
+     
+      coninhcount
+      int4
+      
+      
+       The number of direct ancestors this constraint has.  A constraint with
+       a nonzero number of ancestors cannot be dropped nor renamed
+      
+     
+
      
       conkey
       int2[]

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 98233866300c6e3c50d1d16e310f2c842d7bd03a..183d1e89f5ff7119317176bd86e0ac13be6e9ef5 100644 (file)
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Data Definition
@@ -2107,7 +2107,8 @@ VALUES ('New York', NULL, NULL, 'NY');
 
   
    A parent table cannot be dropped while any of its children remain. Neither
-   can columns of child tables be dropped or altered if they are inherited
+   can columns or check constraints of child tables be dropped or altered
+   if they are inherited
    from any parent tables. If you wish to remove a table and all of its
    descendants, one easy way is to drop the parent table with the
    CASCADE option.
@@ -2117,7 +2118,7 @@ VALUES ('New York', NULL, NULL, 'NY');
     will
    propagate any changes in column data definitions and check
    constraints down the inheritance hierarchy.  Again, dropping
-   columns or constraints on parent tables is only possible when using
+   columns that are depended on by other tables is only possible when using
    the CASCADE option. ALTER
    TABLE follows the same rules for duplicate column merging
    and rejection that apply during CREATE TABLE.

diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index d6bf184d649e54ee867136941a456b8e86355415..ab929728a7ff5c7647bc214936ecd672a640dd09 100644 (file)
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -1,5 +1,5 @@
 
 
@@ -713,7 +713,8 @@ ALTER TABLE table ALTER COLUMN anycol TYPE anytype;
     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.
+    Adding a constraint can recurse only for CHECK constraints,
+    and is required to do so for such constraints.
    
 
    
@@ -804,7 +805,7 @@ ALTER TABLE distributors ALTER COLUMN street DROP NOT NULL;
   
 
    
-   To add a check constraint to a table:
+   To add a check constraint to a table and all its children:
 
 ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK (char_length(zipcode) = 5);
 
@@ -817,6 +818,14 @@ ALTER TABLE distributors DROP CONSTRAINT zipchk;
 
   
 
+   
+   To remove a check constraint from a table only:
+
+ALTER TABLE ONLY distributors DROP CONSTRAINT zipchk;
+
+   (The check constraint remains in place for any child tables.)
+  
+
    
    To add a foreign key constraint to a table:
 

diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
index 68e8f045e6aaf454f9829dbec75011c34e31f3dd..ef28a8d21529046a6d3251246c6b1505622fcc7c 100644 (file)
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -1,5 +1,5 @@
 
 
@@ -210,16 +210,25 @@ and table_constraint is:
       the new table.  If the column name list of the new table
       contains a column name that is also inherited, the data type must
       likewise match the inherited column(s), and the column
-      definitions are merged into one.  However, inherited and new
-      column declarations of the same name need not specify identical
-      constraints: all constraints provided from any declaration are
-      merged together and all are applied to the new table.  If the
+      definitions are merged into one.  If the
       new table explicitly specifies a default value for the column,
       this default overrides any defaults from inherited declarations
       of the column.  Otherwise, any parents that specify default
       values for the column must all specify the same default, or an
       error will be reported.
      
+
+     
+      CHECK constraints are merged in essentially the same way as
+      columns: if multiple parent tables and/or the new table definition
+      contain identically-named CHECK constraints, these
+      constraints must all have the same check expression, or an error will be
+      reported.  Constraints having the same name and expression will
+      be merged into one copy.  Notice that an unnamed CHECK
+      constraint in the new table will never be merged, since a unique name
+      will always be chosen for it.
+     
+