On 3/3/25 02:05, Peter Eisentraut wrote:
> In the theory of the SQL standard, executing referential actions and checking 
the foreign-key
> constraint are two separate steps.  So it kind of goes like this:
>
> 1. run command
> 2. run any referential actions
> 3. check that foreign key is still satisfied
>
> This is why the default referential action is called "NO ACTION": It just 
skips the step 2.  But it
> still does step 3.
>
> This means that under RESTRICT and with my interpretation, the check for a 
RESTRICT violation in
> step 2 can "ignore" the period part, but the step 3 still has to observe the 
period part.
>
> In the implementation, these steps are mostly combined into one trigger 
function, so it might be a
> bit tricky to untangle them.

I understand that there are those separate steps. But it still doesn't make sense for RESTRICT to ignore the temporal part of the key. Actually, talking about "actions" reminds me of another reason: the effect of CASCASE/SET NULL/SET DEFAULT actions should also be limited to only the part of history that was updated/deleted in the referenced row. (This is why their implementation depends on FOR PORTION OF.) Otherwise a temporal CASCADE/SET NULL/SET DEFAULT would wreck havoc on your data. But if that's how these other actions behave, shouldn't RESTRICT behave the same way? Again, it's not clear why anyone would want a temporal foreign key that ignores its temporal attribute. And as I explained before, I don't think that's what a careful read of the standard says.

Yours,

--
Paul              ~{:-)
p...@illuminatedcomputing.com



Reply via email to