Re: Transition tables for triggers on foreign tables and views

From: Noah Misch <noah(at)leadboat(dot)com>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Transition tables for triggers on foreign tables and views
Date: 2017-05-08 07:00:20
Message-ID: 20170508070020.GB1089054@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2017-05-08 07:03:58 Re: SUBSCRIPTIONS and pg_upgrade
Previous Message Amit Langote 2017-05-08 06:59:09 Re: multi-column range partition constraint