On Fri, 31 Oct 2003, Jan Wieck wrote:
> Stephan Szabo wrote:
> > On Thu, 30 Oct 2003, Tom Lane wrote:
> >
> >> Stephan Szabo <sszabo@megazone.bigpanda.com> 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.
Yeah. I was worried that it might not carry as much weight especially
towards 7.3 if it was thought to be an odd rule/key interaction rather
than something that can happen very simply with a deferred constraint.