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.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
