SQL deferred constraints (a bit O/T, I know)
From: Roy Hann <specially_at_processed.almost.meat>
Date: Thu, 31 Mar 2011 19:42:58 +0000 (UTC)
Message-ID: <in2lg2$plf$1_at_speranza.aioe.org>
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?
Date: Thu, 31 Mar 2011 19:42:58 +0000 (UTC)
Message-ID: <in2lg2$plf$1_at_speranza.aioe.org>
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.)
-- RoyReceived on Thu Mar 31 2011 - 21:42:58 CEST