From: | 李杰(慎追) <adger(dot)lj(at)alibaba-inc(dot)com> |
---|---|
To: | "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>, "Ashutosh Bapat" <ashutosh(dot)bapat(at)2ndquadrant(dot)com> |
Cc: | "Ashutosh Bapat" <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, "Pg Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | 回复:BEFORE ROW triggers for partitioned tables |
Date: | 2021-01-18 13:03:07 |
Message-ID: | 5a3290db-8ad9-45c3-93b2-e365498431be.adger.lj@alibaba-inc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi commiter,
Many of our customers expect to use BR triggers in partitioned tables.
After I followed your discussion, I also checked your patch.
Here are two questions confusing me:
1. Your modification removes the check BR triggers against partitioned table,
and a more friendly error message is added to the ExecInsert and ExecUpdate.
You are correct. ExecInsert does not reroute partitions.
However, when ExecUpdate modifies partition keys,
it is almost equivalent to ExecDelete and ExecInsert,
and it is re-routed(ExecPrepareTupleRouting) once before ExecInsert. Therefore,
why should an error be thrown in ExecUpdate?
Let's look at a case :
```
postgres=# create table parted (a int, b int, c text) partition by list (a);
CREATE TABLE
postgres=# create table parted_1 partition of parted for values in (1);
CREATE TABLE
postgres=# create table parted_2 partition of parted for values in (2);
CREATE TABLE
postgres=# create function parted_trigfunc() returns trigger language plpgsql as $$
begin
new.a = new.a + 1;
return new;
end;
$$;
CREATE FUNCTION
postgres=# insert into parted values (1, 1, 'uno uno v1');
INSERT 0 1
postgres=# create trigger t before update on parted
for each row execute function parted_trigfunc();
CREATE TRIGGER
postgres=# update parted set c = c || 'v3';
```
If there is no check in the ExecUpdate,
the above update SQL will be executed successfully.
However, in your code, this will fail.
So, what is the reason for your consideration?
2. In this patch, you only removed the restrictions BR trigger against
the partitioned table, but did not fundamentally solve the problem caused
by modifying partition keys in the BR trigger. What are the difficulties in
solving this problem fundamentally? We plan to implement it.
Can you give us some suggestions?
We look forward to your reply.
Thank you very much,
Regards, Adger
------------------------------------------------------------------
发件人:Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
发送时间:2021年1月18日(星期一) 20:36
收件人:Ashutosh Bapat <ashutosh(dot)bapat(at)2ndquadrant(dot)com>
抄 送:Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>; Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
主 题:Re: BEFORE ROW triggers for partitioned tables
Thanks for the reviews; I have pushed it now.
(I made the doc edits you mentioned too.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2021-01-18 13:03:42 | Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit |
Previous Message | 李杰 (慎追) | 2021-01-18 12:59:37 | 回复:BEFORE ROW triggers for partitioned tables |