| From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
|---|---|
| To: | rdkennedy(at)acm(dot)org |
| Cc: | pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: Table Constraint CHECK(SELECT()) alternative? |
| Date: | 2005-09-06 04:25:08 |
| Message-ID: | 20050905211839.U4939@megazone.bigpanda.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
On Sat, 3 Sep 2005, Robert D. Kennedy wrote:
> I have seen in another thread that sub-queries in a CHECK
> constraint have implementation ramifications that make them awkward to
> implement and support. OK, fair enough, c'est la vie.
>
> ERROR: cannot use subquery in check constraint
>
> is the result. I have a model which seems to BEG for just such a feature
> though. What alternatives are there to the use of CHECK(SELECT()) in
> this model?
The simplest thing is to place the select into a function and use a check
constraint on that (with appropriate row locks). However, that won't
prevent removal or change of a referenced row.
You can use triggers to prevent that (in your case to prevent removal or
change of id of a referenced node or the change of type of a referenced
mode away from directory). At that point, you might be just as well off
using a trigger to do the initial check as well.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephan Szabo | 2005-09-06 04:30:35 | Re: Weird Trigger Behaviour using IF ... THEN ... ESLEIF... |
| Previous Message | Dinesh Pandey | 2005-09-06 04:18:14 | Re: Table Constraint CHECK(SELECT()) alternative? |