Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Tue, Mar 13, 2018 at 9:27 AM, Tom Lane <tgl@sss.pgh.pa.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