Re: BUG #15106: The AFTER trigger is created separately on view, and the DML operation can not trigger the trigger

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Tue, Mar 13, 2018 at 9:27 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> When there's no INSTEAD OF trigger, the query is rewritten into an insert
>> on the view's base table (assuming the view is simple enough to be
>> auto-updatable), and we fire the base table's statement triggers, not the
>> view's. I'm pretty sure this is intentional, though I couldn't find it
>> mentioned in the manual either. Firing both sets of statement triggers
>> would be confusing, and not firing the base table's triggers would
>> perhaps miss processing that needs to happen.

> We also discussed this here:

> https://www.postgresql.org/message-id/flat/CACjxUsOrn%2B3FgaLzskuLB3hASW6iTUd6f40gq_q80a9NHXk92A%40mail.gmail.com

> We resolved the main issue in that thread but we didn't do anything
> about this side issue. You and Kevin both suggested that perhaps we
> shouldn't allow you to create such unfireable triggers, or perhaps we
> should raise a warning, or at least document the (IMHO) confusing
> behaviour.

A simple approach to raising an error or warning would create hazards
for pg_dump, ie it'd need to make sure the INSTEAD OF trigger was restored
first. We could get around that no doubt, but I don't think it's worth
the work, at least not unless we get a lot more complaints. For the
moment a documentation improvement seems sufficient, so I've pushed one.

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a4678320471380e5159a8d6e89466d74d6ee1739

regards, tom lane