Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable)

Amit Langote <amitlangote09@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