Re: [GENERAL] Cascades Failing

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: [GENERAL] Cascades Failing
Дата
Msg-id 20050821093230.T94481@megazone.bigpanda.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Cascades Failing  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Список pgsql-hackers
On Fri, 19 Aug 2005, Stephan Szabo wrote:

> On Fri, 19 Aug 2005, Tom Lane wrote:
>
> > Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > > Is the correct answer to continue marking and running the triggers until
> > > there are no immediate triggers left to run for this case?
> >
> > Hmm ... my recollection is that we put in the concept of marking because
> > we needed it for correct behavior in some cases.  I don't recall exactly
> > why though.
>

Hmm, there's an issue with before triggers as well.  We add the checks for
the updates to the end of the current statement's queue and shouldn't run
them until all the cascaded updates are done.  However, if a before on
update trigger of the fk side also updates an fk row that is in the middle
of a series of these updates with a direct update statement, that
statement's check will happen inside the before trigger, which will fail.
It's not necessarily a triggered data change violation if the change
happens to not change the key values or sets them to what the have already
or will become. We could get around this by somehow inheriting the state
of our direct parent trigger (whether or not it was in a new query), but
that seems like it'd break other cases because the triggers would line up
in the pre-8.0 sequence in that case. Or, is it correct to fail in this
case because the statement is trying to update in a new query to a set of
invalid keys?




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL 8.0.3 and Ipv6
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL 8.0.3 and Ipv6