-----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