Hiroshi Inoue wrote:
> > From: pgsql-sql-owner@hub.org [mailto:pgsql-sql-owner@hub.org]On
> > Behalf Of Niall Smart
> >
> > CONSTRAINT TYPE_CD_OK CHECK (
> > EXISTS (SELECT 1 FROM XREF WHERE
> > XREF_GROUP = 'CUST_TYPE' AND
> > XREF_CD = TYPE_CD)
> > )
> >
> >
> > > There seems to be more serious problems.
> > > 1) The constraint is not only for the defined table but also
> > for referenced
> > > tables in the subquery.
> >
> > I don't understand what you mean -- the constraint only
> > constrains 1 column in one table...
>
> Doesn't the constraint mean that
> for any row in table CUST,there *always* exist some rows in
> the table XREF such that satisfies XREF_GROUP='CUST_TYPE'
> AND XREF_CD=TYPE_CD ?
>
> If all such rows are deleted from the table XREF,above condition
> isn't satisfied any longer. So isn't the constraint for the table XREF
> either ?
Ah, I see what you mean now. Well, thats an interesting point,
as I originally tried to define the constraint using the
foreign key syntax. Perhaps a better way to support this
functionality is to allow constants in the source columns
of a foreign key constraint, for example:
CONSTRAINT TYPE_CD_OK FOREIGN KEY ('CUST_TYPE' AS XREF_GROUP, XREF_CD) REFERENCES XREF
However I would submit that constraint clauses are
effectively before-insert validation triggers and that
it is up to the database designer to use more robust
methods when they wish to enforce referential integrity.
Note that it is possible to define a CHECK constraint using
a function, in which case it is impossible to determine if
the function is expressing a relational integrity constraint.
Niall
