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 
