Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Sat, Sep 16, 2017 at 7:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Attached is an updated patch that incorporates the ideas you suggested.
> I was imagining that you would just need to keep a back pointer to the
> last queued event for the same (relation, command), since that's the
> only one you'd ever need to consider cancelling, and then no scanning
> would be needed. I am probably missing something.
There could be more than one after-statement trigger, no?
>> This is pretty messy but I think it's the best we can do as long as
>> RI actions are intermixed with other AFTER ROW triggers.
> It does seem like an inconsistency that it would be good to fix, but I
> don't immediately see how to make that happen with the current design.
> It would be interesting to know what DB2 does here in terms of trigger
> execution contexts and transition tables when you have a chain of 2, 3
> and 4 foreign key referential actions.
> Is it worth adding a test with an extra level of chaining in the self_ref case?
Would it show anything not shown by the three-level case?
> Is it worth adding tests for SET NULL and SET DEFAULT, to exercise the
> complete set of referential actions?
I think they're all about the same as far as this is concerned.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs