Re: Transition tables for triggers on foreign tables and views

Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
> On Tue, Apr 25, 2017 at 6:17 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> For views, aside from the question of transition tables, I noticed
>> that statement triggers don't seem to fire at all with updatable
>> views. Surely they should -- isn't that a separate bug?

> I checked out 25dc142a (before any of my commits for $subject),
> built it, and tried the above -- with no warning generated. I then
> used an UPDATE and DELETE against the view, also with no trigger
> fired (nor any error during trigger creation or DML). Does anyone
> know whether such trigger ever fired at any point in the commit
> history?

[ experiments... ] They did, and do, fire if you do it the old-style
way with an INSTEAD OF row trigger. They don't fire if you're relying
on an updatable view. It seems we fire the table's statement triggers
instead, ie, the update is fully translated into an update on the
underlying table.

I'm not sure how intentional that was, but it's not a completely
unreasonable definition on its face, and given the lack of field
complaints since 9.3, I think we should probably stick to it.
However, if you didn't understand that from the documentation,
then we have a documentation problem.

> If we do get these working, don't they deserve at least
> one regression test?

Are you sure there isn't one?

regards, tom lane