On Fri, Apr 28, 2017 at 10:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> They will fire if you have an INSTEAD OF row-level trigger; the existence > of that trigger is what determines whether we implement DML on a view > through the view's own triggers or through translation to an action on > the underlying table. > > I do not think it'd be reasonable to throw an error for creation of > a statement-level view trigger when there's no row-level trigger, > because that just imposes a hard-to-deal-with DDL ordering dependency. > > You could make a case for having the updatable-view translation code > print a WARNING if it notices that there are statement-level triggers > that cannot be fired due to the translation. Oh, I see -- you can add all the AFTER ... FOR EACH STATEMENT triggers you want for an updatable view and they will quietly sit there without firing no matter how many statements perform the supposedly triggering action, but as soon as you add a INSTEAD OF ... FOR EACH ROW trigger they spring to life. On the face of it that seems to me to violate the POLA, but I kinda see how it evolved. I need to look at this and the rather similar odd behavior under inheritance. I hope to post something Friday. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
