Re: 7.4RC1 planned for Monday
От | Jan Wieck |
---|---|
Тема | Re: 7.4RC1 planned for Monday |
Дата | |
Msg-id | 3FA295A3.3040608@Yahoo.com обсуждение исходный текст |
Ответ на | Re: 7.4RC1 planned for Monday (Stephan Szabo <sszabo@megazone.bigpanda.com>) |
Ответы |
Re: 7.4RC1 planned for Monday
|
Список | pgsql-hackers |
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 #
В списке pgsql-hackers по дате отправления: