From: | David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #11107: UPDATE violates table check constraint |
Date: | 2014-08-01 17:30:27 |
Message-ID: | CAKFQuwbrwpPax=gCxKqPoHgEvByMjWihktt4Ty-4r_Z7FZ1Tnw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Aug 1, 2014 at 10:01 AM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
> On 8/1/14 5:59 PM, David G Johnston wrote:
>
>> Tom Lane-2 wrote
>>
>>> Sorry, but this check constraint has entirely undefined behavior, as does
>>> any check constraint that refers to data rows other than the one that is
>>> being checked.
>>>
>>
>> Which is why PostgreSQL has CREATE TRIGGER functionality...
>>
>
> Which does absolutely nothing to get rid of the race conditions.
>
>
True enough - but at least it would theoretically work in their absence.
Two more useful model designs to consider:
1) Make the FK composite
2) Remove the duplicate PK dependent data from the foreign table
Though given that we only have a toy model to work, and no problem/domain
description, all suggestions are thought-provoking only.
Lacking a model change you could encapsulate both constraints and races
within a function and disallow direct updates to the key-related columns.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Lars Ewald (web.de) | 2014-08-01 17:59:23 | Re: Fwd: Re: Compile fails on AIX 6.1 |
Previous Message | Marko Tiikkaja | 2014-08-01 17:01:54 | Re: BUG #11107: UPDATE violates table check constraint |