From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 691525127(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15106: The AFTER trigger is created separately on view, and the DML operation can not trigger the trigger |
Date: | 2018-03-12 22:33:32 |
Message-ID: | CAEepm=0UZpJMR26VBXM6a_1N-Q75m4=6L5+uEk=ky+7AnNknow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Mar 13, 2018 at 9:27 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> =?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
>> It can be seen from the above example, the DML operation cannot trigger the
>> trigger when the Statement-level AFTER trigger is created on view alone.
>> But when create INSTEAD OF trigger at the same time, the DML operation can
>> trigger the AFTER trigger.
>
> 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:
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.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Patrick Krecker | 2018-03-13 02:05:42 | Re: BUG #15104: Double free in the main function in ecpg.c |
Previous Message | Tom Lane | 2018-03-12 22:22:13 | Re: Weird return-value from pg_get_function_identity_arguments() on certain aggregate functions? |