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: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Subject: Re: Transition tables for triggers on foreign tables and views
Date: 2017-05-02 04:28:06
Message-ID: 20170502042806.GA834613@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 28, 2017 at 05:07:31AM +0000, Noah Misch wrote:
> On Wed, Apr 26, 2017 at 11:17:05AM +1200, Thomas Munro wrote:
> > My colleague Prabhat Sahu reported off list that transition tables
> > don't work for views. I probably should have thought about that when
> > I fixed something similar for partitioned tables, and after some
> > experimentation I see that this is also broken for foreign tables.
> >
> > For foreign tables using postgres_fdw, I see that transition tables
> > capture new rows for INSERT but capture nothing for DELETE and UPDATE.
> >
> > For views, aside from the question of transition tables, I noticed
> > that statement triggers don't seem to fire at all with updatable
> > views. Surely they should -- isn't that a separate bug?
> >
> > Example:
> >
> > create table my_table (i int);
> > create view my_view as select * from my_table;
> > create function my_trigger_function() returns trigger language plpgsql as
> > $$ begin raise warning 'hello world'; return null; end; $$;
> > create trigger my_trigger after insert or update or delete on my_view
> > for each statement execute procedure my_trigger_function();
> > insert into my_view values (42);
> >
> > ... and the world remains ungreeted.
> >
> > As for transition tables, there are probably meaningful ways to
> > support those for both views and foreign tables at least in certain
> > cases, as future feature enhancements. For now, do you agree that we
> > should reject such triggers as unsupported? See attached.
>
> [Action required within three days. This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 10 open item. Kevin,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is more relevant or if this does not belong as a
> v10 open item, please let us know. Otherwise, please observe the policy on
> open item ownership[1] and send a status update within three calendar days of
> this message. Include a date for your subsequent status update. Testers may
> discover new open items at any time, and I want to plan to get them all fixed
> well in advance of shipping v10. Consequently, I will appreciate your efforts
> toward speedy resolution. Thanks.
>
> [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-05-02 05:12:41 Re: Potential hot-standby bug around xacts committed but in xl_running_xacts
Previous Message Vaishnavi Prabakaran 2017-05-02 04:19:23 Re: vcregress support for single TAP tests