From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
---|---|
To: | "Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)com> |
Cc: | Igor Neyman <ineyman(at)perceptron(dot)com>, Mike Christensen <mike(at)kitchenpc(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Constraint to ensure value does NOT exist in another table? |
Date: | 2011-06-16 13:56:13 |
Message-ID: | BANLkTinSSPzV=Z6ijkRoDKcRBUUrhS-dUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 16 June 2011 14:41, Gauthier, Dave <dave(dot)gauthier(at)intel(dot)com> wrote:
> I've dealt with something similar by using a check constraint and a stored procedure. The check constraint calls a stored procedure, passing it (in your case) the key you want to make sure doesn't exist in some other table. The stored procedures queries that other table for the key and passes back a YES/NO flag that the check constraint detects and acts on (constraint violated or not).
>
> I'm not using this to check a prim/foreign key relationship for my app, and the table that the stored procedure is querying is a ref table that is very static. This approach may not be bullet proof for checking key relationships in dynamic tables. I'll let others speak to that.
Did you use explicit locking? If not, you likely have a race
condition. The same applies to any sort of enforcement of business
rules inside triggers (or, indeed, check constraints). Check
constraints are generally intended to enforce simple, immutable rules
(i.e. that only reference the tuple that the rule is enforced on). I
would have used a trigger instead.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-06-16 13:58:08 | Re: order by and view def. |
Previous Message | Merlin Moncure | 2011-06-16 13:55:28 | Re: Encryption For Specific Column- Where to store the key |