Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Thu, Sep 14, 2017 at 10:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> BTW, as I'm digging around in trigger.c, I can't help noticing that
>> it provides a single "fdw_tuplestore" per trigger query level (a/k/a
>> trigger execution context). I've not tried to test this, but it
>> sure looks like a wCTE like your example above, directed at two
>> separate foreign tables with triggers, would fail for exactly the
>> same reason. That'd be a bug of pretty long standing.
> I had the impression that that fdw_tuplestore was doing something a
> bit sneaky that actually works out OK: tuples get enqueued and later
> dequeued in exactly the same sequence as the after row trigger events
> that need them, so even though it seems to violate at least the POLA
> if not the spirit of tuplestores by storing tuples of potentially
> different types in one tuplestore, nothing bad should happen.
Oh? Now my fear level is up to 11, because it is completely trivial to
cause triggers to fire in a different order than they were enqueued.
All you need is a mix of deferrable and nondeferrable triggers.
In fact, it also seems entirely broken that a per-query-level tuplestore
is being used at all, because deferrable triggers might not get fired
until some outer query level.
[ Pokes around... ] Hm, looks like we get around that by forbidding
constraint triggers on foreign tables, but I don't see anything in the
CREATE TRIGGER man page saying that there's such a prohibition. And
there's certainly no comments in the source code explaining this rickety
set of requirements :-(
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