On Thu, Jun 14, 2018 at 1:54 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2018/06/12 22:22, Ashutosh Bapat wrote: >> -- create triggers, user may create different trigger functions one >> for each partition, unless s/he understands that the tables can share >> trigger functions >> create function trig_t1p1() returns trigger as $$ begin return new; >> end;$$ language plpgsql; >> create trigger trig_t1p1_1 before update on t1p1 execute procedure >> trig_t1p1(); >> create trigger trig_t1p1_2 before update on t1p1 execute procedure >> trig_t1p1(); >> >> create function trig_t1p2() returns trigger as $$ begin return new; >> end;$$ language plpgsql; >> create trigger trig_t1p2 before update on t1p2 execute procedure trig_t1p2(); >> >> When this schema gets upgraded to v12 or whatever version supports >> BEFORE ROW triggers on a partitioned table and the user tries to >> create a trigger on a partitioned table >> 1. somehow the code has to detect that there are already triggers on >> the partitions so no need to create new triggers on the partitions. I >> don't see how this can be done, unless the user is smart enough to use >> the same trigger function for all partitions. >> >> 2. user has to drop those triggers and trigger functions and create >> trigger on the partitioned table. >> >> May be I am underestimating users but I am sure there will be some >> users who will end up with scenario. > > Hmm, if a user *knowingly* makes triggers on different partitions call > different functions, then they wouldn't want to use the feature to create > the trigger on partitioned tables, because that feature implies same > trigger definition for all partitions.
How many users would do that *knowingly*? > > Maybe, just as a reminder to users, we could mention in the docs that it > is in fact possible to call the same function from different triggers > (that is, triggers defined on different partitions) and that's what they > should do if they intend to later use the feature to define that same > trigger on the partitioned table. +1 for something like this, but wording is important. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
