On Fri, Mar 24, 2017 at 1:14 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> If that's fixed and the permissions question can be waved away by
> saying it's the same as the per-row situation, my only other comment
> would be a bikeshed issue: Enr isn't a great name for a struct.
One more thought: should this be allowed?
postgres=# create table mytab (i int) partition by list (i);
CREATE TABLE
postgres=# create table mytab1 partition of mytab for values in (42);
CREATE TABLE
postgres=# create function my_trigger_function() returns trigger as $$
begin end; $$ language plpgsql;
CREATE FUNCTION
postgres=# create trigger my_trigger after update on mytab referencing
old table as my_old for each statement execute procedure
my_trigger_function();
CREATE TRIGGER
I haven't really looked into the interaction of triggers and the new
partition feature very much but it looks like the intention is that
you shouldn't be allowed to do something that would need access to the
actual row data from a trigger that is attached to the top-level
partition:
postgres=# create trigger my_trigger before update on mytab for each
row execute procedure my_trigger_function();
ERROR: "mytab" is a partitioned table
DETAIL: Partitioned tables cannot have ROW triggers.
By the same logic, I guess that we shouldn't allow transition table
triggers to be attached to the top level partitioned table, because it
can't really work.
You can attach ROW triggers to the concrete tables that hold real
data, which makes sense because they actually have data to capture and
feed to the trigger function:
postgres=# create trigger my_trigger before update on mytab1 for each
row execute procedure my_trigger_function();
CREATE TRIGGER
Perhaps the moral equivalent should be possible for statement triggers
with transition tables, and that already works with your patch as far
as I know. So I think your patch probably just needs to reject them
on partitioned tables.
--
Thomas Munro
http://www.enterprisedb.com
