RE: Bug in FOREIGN KEY

-----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)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 corresponding fk
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