Skip site navigation (1) Skip section navigation (2)

Re: 7.4RC1 planned for Monday

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 7.4RC1 planned for Monday
Date: 2003-10-31 17:02:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Stephan Szabo wrote:
> On Thu, 30 Oct 2003, Tom Lane wrote:
>> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)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.


# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2003-10-31 17:02:57
Subject: Re: Call for port reports
Previous:From: Bruce MomjianDate: 2003-10-31 16:42:20
Subject: Re: Experimental patch for inter-page delay in VACUUM

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group