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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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