RE: Bug in FOREIGN KEY

-----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 
> > However I'm suspicious if KEY_CHANGED check is necessary.
> > Removing KEY_CHANGED stuff seems to solve the TODO 
> >   FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
> > though it may introduce other bugs. 
> 
> I suspect it just masks the problem by preventing the trigger code
> from executing ...
>

I've examined the new TODO * FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
a little and am now wondering why it has remained unsolved until now.

ISTM there are 2 different RI related issues.
1) "begin; insert; delete(or update pk of) the inserted tuple"   causes a "change violation" error.
2) For deferred RI constraints   "begin;delete a pk;insert the same pk;commit;"   fails(or misbehaves) in case the
correspondingfk   exist.
 

Shouldn't we distinguish above 2 issues clearly ?
And doesn't the new TODO correspond to 1) ?
The issue 1) seems to be caused due to the transaction-wide
KEY_CHANGED check. Isn't it sufficient to check KEY_CHANGED
per query. For example, how about clearing KEY_CHANGED after
every DeferredTriggerEndQeury() ?

Regards,
Hiroshi Inoue