Re: BUG #4709: dump/restore introduces wrong CHECK constraint for inherited table - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #4709: dump/restore introduces wrong CHECK constraint for inherited table
Date
Msg-id 6887.1237293401@sss.pgh.pa.us
Whole thread Raw
In response to BUG #4709: dump/restore introduces wrong CHECK constraint for inherited table  ("Andrey" <andrey@ulab.ru>)
List pgsql-bugs
"Andrey" <andrey@ulab.ru> writes:
> Assume we have 2 tables with additionally added CHECK constraints:
> ...
> ALTER TABLE ONLY t ADD CONSTRAINT type_eq_zero CHECK (type = 0);

The way this is addressed in CVS HEAD is that such commands are
forbidden:

regression=# ALTER TABLE ONLY t ADD CONSTRAINT type_eq_zero CHECK (type = 0);
ERROR:  constraint must be added to child tables too

An "ONLY" check constraint isn't very reasonable because then the table
would appear to contain rows that violate the constraint.  What I'd
suggest for what you seem to be trying to accomplish is to have an
empty parent table and two child tables, each with a constraint
restricting the "type" column.  The information on partitioning in the
manual might help you, since this is fundamentally a partitioning setup.

The behavior of 8.3 and before in this regard won't be changed.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Andrey"
Date:
Subject: BUG #4709: dump/restore introduces wrong CHECK constraint for inherited table
Next
From: "Oleg"
Date:
Subject: BUG #4710: Bug with sql functions, when using INSERT.. RETURNING .. statment