Amit Langote <amitlangot...@gmail.com> writes: > Updated to replace a list_nth() with list_nth_node() and rewrote the > commit message.
So I was working through this with intent to commit, when I realized that the existing code it's revising is flat out broken. You can't simply translate a parent rel's set of dependent generated columns to obtain the correct set for a child. Maybe that's sufficient for partitioned tables, but it fails miserably for general inheritance: regression=# create table pp(f1 int); CREATE TABLE regression=# create table cc(f2 int generated always as (f1+1) stored) inherits(pp); CREATE TABLE regression=# insert into cc values(42); INSERT 0 1 regression=# table cc; f1 | f2 ----+---- 42 | 43 (1 row) regression=# update pp set f1 = f1*10; UPDATE 1 regression=# table cc; f1 | f2 -----+---- 420 | 43 (1 row) So we have a long-standing existing bug to fix here. I think what we have to do basically is repeat what fill_extraUpdatedCols does independently for each target table. That's not really horrible: given the premise that we're moving this calculation into the planner, we can have expand_single_inheritance_child run the code while we have each target table open. It'll require some rethinking though, and we will need to have the set of update target columns already available at that point. This suggests that we want to put the updated_cols and extraUpdatedCols fields into RelOptInfo not PlannerInfo. regards, tom lane