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 20170510024505.GA1293561@rfd.leadboat.com
Whole thread Raw
In response to Re: [HACKERS] Transition tables for triggers on foreign tables and views  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] Transition tables for triggers on foreign tables and views  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Mon, May 08, 2017 at 12:00:20AM -0700, Noah Misch wrote:
> On Sat, May 06, 2017 at 06:58:35PM +0000, Noah Misch wrote:
> > 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
> 
> IMMEDIATE ATTENTION REQUIRED.  This PostgreSQL 10 open item is long past due
> for your status update.  Please reacquaint yourself with the policy on open
> item ownership[1] and then reply immediately.  If I do not hear from you by
> 2017-05-09 07:00 UTC, I will transfer this item to release management team
> ownership without further notice.
> 
> [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com

This PostgreSQL 10 open item now needs a permanent owner.  Would any other
committer like to take ownership?  If this role interests you, please read
this thread and the policy linked above, then send an initial status update
bearing a date for your subsequent status update.  If the item does not have a
permanent owner by 2017-05-13 03:00 UTC, I will resolve the item by reverting
transition table patches.

Thanks,
nm



pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: [HACKERS] idea: custom log_line_prefix components besidesapplication_name
Next
From: Noah Misch
Date:
Subject: Re: [HACKERS] delta relations in AFTER triggers