Thomas Munro <thomas.munro@enterprisedb.com> writes:
> Aside from the RI case, the other user visible change in behaviour
> will be for statements that update the same table via multiple
> ModifyTable nodes (wCTEs). Our regression test has:
> with wcte as (insert into table1 values (42))
> insert into table2 values ('hello world');
> ... which demonstrates the fix for the original complaint that table1
> and table2 earlier tried to use the same transition table (and
> crashed). A new variant inserting into table1 twice would show the
> difference. Today we get:
> postgres=# with wcte as (insert into table1 values (42))
> insert into table1 values (43);
> NOTICE: trigger = table1_trig, new table = (43,)
> NOTICE: trigger = table1_trig, new table = (42,)
> INSERT 0 1
> Presumably with your change there will be a single transition table
> for inserts into table, holding both (42,) and (43,). But will we
> fire the trigger once or twice?
Not necessarily. That would be true only if we allow the WCTE to share
trigger context with the outer query, which I think it does not today.
I've not checked the code, but presumably if we fire the trigger twice
right now, that means there are separate trigger contexts, ie somebody
is calling AfterTriggerBeginQuery/AfterTriggerEndQuery around the WCTE.
If not, maybe we could make it do so. OTOH, looking at the text of
the spec, I think it's darn hard to justify the behavior shown above.
The reason that the RI case would share trigger context with the outer
query is that we'd *not* call AfterTriggerBeginQuery/AfterTriggerEndQuery
around the RI query, which would be driven by the same skip_trigger
logic that exists today.
>> This seems like rather a mess to implement. I wonder whether I'm
>> reading it right, and whether other DBMSes actually implement it
>> like that.
> I guess the alternative is storing extra per-tuple metadata,
> transferring more work to the reader.
I really don't want any more per-tuple state. Adding the TCS link
was costly enough in terms of how big the tuple queue storage is.
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
