Re: BUG #16272: Index expression can refer to wrong attributes if index is created via CREATE TABLE LIKE

I wrote:
> I did some more investigation of this today. There are at least three
> related bugs in this vicinity:
> * Vars in CHECK constraints coming from LIKE ... INCLUDING CONSTRAINTS
> are not renumbered when they need to be.
> * Vars in GENERATED expressions coming from LIKE ... INCLUDING GENERATED
> are not renumbered when they need to be.
> * Vars in GENERATED expressions coming from inheritance parents
> are not renumbered when they need to be.
> The attached proposed patch fixes those three things. But it fails
> to fix the initially-complained-of problem with indexes, because the
> indexes are not part of the CreateStmt data structure received by
> DefineRelation. Still, this is progress towards that, because at
> least we are now building an AttrMap that would be appropriate to use
> for that purpose. The remaining problem is to be able to apply that
> AttrMap to the IndexStmt(s).
> One idea is to pass in the list of statements generated by
> transformCreateStmt to DefineRelation and let it hack on them.
> That seems like an enormous violation of modularity, though.
> Another, perhaps marginally cleaner, answer is to pass back
> the AttrMap and let ProcessUtility hack up the IndexStmts
> as it loops over the list.

I thought of a somewhat less messy answer, which is to divide the
existing transformTableLikeClause processing into two phases, one of
which is delayed until after we've performed DefineRelation. At that
point it's no problem to convert everything from the LIKE parent
table's attnums to the new child's. MergeAttributes still has to
fix up GENERATED expressions passed down from traditional-inheritance
parents, but that does not require abusing its API like the previous
patch did.

So attached is a complete fix for the issues discussed in this thread.

Although I originally felt that we weren't going to be able to create
a back-patchable fix, this seems much less invasive than my prior
attempt, so I think it might be reasonable to back-patch. The only
external API break is the new AT_CookedColumnDefault subcommand,
which we could stick at the end of the enum in stable branches.

Thoughts?

regards, tom lane