Re: sub-selects in CHECK - Mailing list pgsql-hackers

From nconway@klamath.dyndns.org (Neil Conway)
Subject Re: sub-selects in CHECK
Date
Msg-id 20020727233627.GA1254@klamath.dyndns.org
Whole thread Raw
In response to Re: sub-selects in CHECK  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: sub-selects in CHECK  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jul 27, 2002 at 07:07:13PM -0400, Tom Lane wrote:
> nconway@klamath.dyndns.org (Neil Conway) writes:
> > I'd like to add the ability to use a sub-select in a CHECK constraint.
> > Can someone elaborate on what changes would be needed to support
> > this?
> 
> Define what you think should happen when the other rows referenced
> by the subselect change.

Good point -- but given that SQL99 specifically mentions that this
functionality should be available (Feature 671, "Subqueries in
CHECK constraints"), there must be some reasonable behavior
adopted by another DBMS...

In any case, there are already plenty of ways to create non-sensical
constraints. For example:

CHECK ( foo < random() )

or even:

CREATE FUNCTION check_func() returns int as 'select ...' language 'sql';

ALTER TABLE foo ADD CONSTRAINT check_x CHECK (x > check_func() );

(which is effectively a sub-select with a different syntax)

So the restrictions "no sub-selects or aggregates in a CHECK constraint"
is quite insufficient, if we actually want to prevent an application
developer from creating dubious constraints.

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: sub-selects in CHECK
Next
From: Tom Lane
Date:
Subject: Re: sub-selects in CHECK