Re: BUG #11107: UPDATE violates table check constraint

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.

In response to

Browse pgsql-bugs by date

  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