On Thu, 30 Oct 2003, Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes: > On Thu, 30 Oct 2003, Tom Lane wrote: >> rule/foreign key interaction reported by Michele Bendazzoli
> In the interests of disclosure, if the case in question for the rule > fails, almost certainly deferred fk constraints will as well which I > think makes this a must fix for 7.4 and is another push to getting a > 7.3.5.
Hm, does Jan's just-committed fix address the concern you had?
Head now passes the case I'd thought of:
create table ta1(a int primary key); create table ta2(a int references ta1 initially deferred); begin; insert into ta2 values (3); update ta2 set a=3 where a=3; -- should error, but might not if the update isn't checked end;
That is basically the same what happened due to Michele's rule. Deferring of the constraint was done there implicitly since both queries resulted from the same statement through rule expansion and the update touched the just inserted row. HEAD and REL7_3_STABLE are safe against this now.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
