Skip site navigation (1) Skip section navigation (2)

Re: BUG #4709: dump/restore introduces wrong CHECK constraint for inherited table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Andrey" <andrey(at)ulab(dot)ru>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4709: dump/restore introduces wrong CHECK constraint for inherited table
Date: 2009-03-17 12:36:41
Message-ID: 6887.1237293401@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Andrey" <andrey(at)ulab(dot)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

In response to

pgsql-bugs by date

Next:From: OlegDate: 2009-03-17 12:54:07
Subject: BUG #4710: Bug with sql functions, when using INSERT.. RETURNING .. statment
Previous:From: AndreyDate: 2009-03-17 12:01:41
Subject: BUG #4709: dump/restore introduces wrong CHECK constraint for inherited table

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group