From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | nconway(at)klamath(dot)dyndns(dot)org (Neil Conway) |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sub-selects in CHECK |
Date: | 2002-07-28 00:48:24 |
Message-ID: | 8107.1027817304@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
nconway(at)klamath(dot)dyndns(dot)org (Neil Conway) writes:
> 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...
It's effectively equivalent to a database-wide assertion, which is
another SQL feature that we don't support.
> In any case, there are already plenty of ways to create non-sensical
> constraints.
Certainly, but this one isn't really ill-defined, it's just very
difficult to support in any acceptably-efficient manner.
If you want to cheat horribly, ie have the condition checked only when a
single-row constraint would be checked, then you can stick the subselect
inside a function call. I don't think we are really adding any
functionality unless we can do better than that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert E. Bruccoleri | 2002-07-28 03:45:07 | Re: Question about LWLockAcquire's use of semaphores instead of spinlocks |
Previous Message | Neil Conway | 2002-07-27 23:36:27 | Re: sub-selects in CHECK |