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

Re: CHECK evaluation error when using more than one table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pmalves(at)cosmos(dot)inesc(dot)pt, pgsql-bugs(at)postgresql(dot)org
Subject: Re: CHECK evaluation error when using more than one table
Date: 2000-11-26 18:27:25
Message-ID: 5084.975263245@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
pgsql-bugs(at)postgresql(dot)org writes:
> CREATE TABLE ninhada (
>     c_id_mae int,
>     n_id int,
>     c_id_pai int,
>     n_dta_nasc date,
>     PRIMARY KEY (n_id, c_id_mae), 
>     FOREIGN KEY (c_id_mae) REFERENCES caes (c_id)
>        ON DELETE CASCADE,
>     FOREIGN KEY (c_id_pai) REFERENCES caes (c_id)
>    ,
>      CHECK (c_id_mae in 
>         (select c.c_id from caes c  where caes.c_id=c_id_mae AND c.c_sexo=0) 
>      )
> );

Sub-selects aren't supported in CHECK constraints (and 7.1 will give
an error message to that effect, rather than bombing out at runtime).

The semantics of such a thing aren't very clear anyway: which rows of
which tables are being constrained?  In the general case we'd have to
re-execute the check expression for every row of its table after any
modification to any row of that table or any other one referenced in
the CHECK clause.  That's not going to be practical.

You could fake it by putting the sub-select in a function, but be aware
that the function is only going to be called at insert or update of
a row of ninhada; there isn't any cross-check on updates to caes
that may invalidate ninhada rows.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: pgsql-bugsDate: 2000-11-26 20:28:24
Subject: Fails to add function from file with \i in psql
Previous:From: pgsql-bugsDate: 2000-11-26 15:57:33
Subject: CHECK evaluation error when using more than one table

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