Re: [HACKERS] Transition tables for triggers on foreign tables and views - Mailing list pgsql-hackers

From Noah Misch
Subject Re: [HACKERS] Transition tables for triggers on foreign tables and views
Date
Msg-id 20170506185835.GI843225@rfd.leadboat.com
Whole thread Raw
In response to Re: [HACKERS] Transition tables for triggers on foreign tables and views  (Kevin Grittner <kgrittn@gmail.com>)
Responses Re: [HACKERS] Transition tables for triggers on foreign tables and views  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Tue, May 02, 2017 at 06:06:47PM -0500, Kevin Grittner wrote:
> On Fri, Apr 28, 2017 at 10:56 PM, Tom Lane <tgl@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.

This PostgreSQL 10 open item is past due for your status update.  Kindly send
a status update within 24 hours, and include a date for your subsequent status
update.  Refer to the policy on open item ownership:
https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: [HACKERS] Re: transition table behavior with inheritance appears broken (was:Declarative partitioning - another take)
Next
From: Noah Misch
Date:
Subject: Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression