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 по дате отправления: