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 20170502042806.GA834613@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>)
List 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



pgsql-hackers by date:

Previous
From: Vaishnavi Prabakaran
Date:
Subject: Re: [HACKERS] vcregress support for single TAP tests
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Potential hot-standby bug around xacts committed but in xl_running_xacts