RE: [HACKERS] Bug in FOREIGN KEY

[Hiroshi Inoue]

-----Original Message----- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > > > 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