Re: SQL deferred constraints (a bit O/T, I know)

From: Roy Hann <specially_at_processed.almost.meat>
Date: Mon, 4 Apr 2011 09:17:46 +0000 (UTC)
Message-ID: <inc2bq$eit$1_at_speranza.aioe.org>


Erwin wrote:

> On 31 mrt, 21:42, Roy Hann <specia..._at_processed.almost.meat> wrote:
>> This is probably not the proper place to pose a question about how SQL
>> "should" work, but I don't know of a better one.  Any suggestions?  
>>
>> I am curious to know the moment to which a deferred constraint should be
>> understood to be deferred.  I assume it should be after the last
>> update in a transaction (signalled by a COMMIT) but before the
>> transaction surrenders read consistency.  But if that's the case,
>> one can construct a pair of concurrent transactions that
>> severally satisfy all constraints yet jointly leave the database
>> inconsistent.   So what's the defined behaviour?  (At this moment I'm
>> not interested in what we'd like it to be; I want to know what the
>> standards define it to be.)
>>
>> --
>> Roy
>
> Roy, I am curious to know what kind of concurrent transactions you are
> thinking of fabricating.
>
> Are you thinking of scenario's in which the concurrency control
> mechanism is MVCC, and the constraint checking too happens under
> MVCC ?
Yes, but when I posed the question I was unaware that the SQL standard requires constraint checking to done using serializable isolation *regardless* of the isolation level of the updating transaction. Obviously if you insist on serializable isolation a lot of easy-to-contrive violations are impossible.

-- 
Roy
Received on Mon Apr 04 2011 - 11:17:46 CEST

Original text of this message