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 20170428050731.GC278614@rfd.leadboat.com
Whole thread Raw
In response to [HACKERS] Transition tables for triggers on foreign tables and views  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] Transition tables for triggers on foreign tables and views  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [HACKERS] some review comments on logical rep code
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders