Re: BUG #16272: Index expression can refer to wrong attributes if index is created via CREATE TABLE LIKE
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: tom@intevation.de
Cc: pgsql-bugs@lists.postgresql.org,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2020-04-27T00:53:35Z
Lists: pgsql-bugs
Attachments
- fix-missing-Var-remaps-with-LIKE-and-inheritance.patch (text/x-diff) patch
I wrote: > PG Bug reporting form <noreply@postgresql.org> writes: >> The index expression in the index created via LIKE ... INCLUDING INDEXES >> still refers to the first two attributes of the table, although an attribute >> has been put in place before the columns the expression referred to in the >> original index. > Ugh. So the problem here is that transformTableLikeClause carefully > renumbers the Vars in the index expression to match the new column > numbers ... as they stand when it runs, which is before any account > has been taken of inheritance. It looks like Vars in check constraints > are likewise misprocessed, and probably GENERATED expressions as well. 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 can't avoid the impression that we ought to rewrite all this logic ... DefineRelation was rather ugly even when we got it from Berkeley, and we've layered more ugliness on it over the years. But I'm not sure offhand what a nicer design would look like. regards, tom lane
Commits
-
Use the properly transformed RangeVar for expandTableLikeClause().
- f11210013d02 11.10 landed
- b380484a850b 13.0 landed
- 86b8ef139457 9.5.24 landed
- 783a21eff37e 10.15 landed
- 1a9c93ec3b9a 9.6.20 landed
- 19f5a37b9fc4 14.0 landed
- 1371a1e4161a 12.5 landed
-
Fix handling of CREATE TABLE LIKE with inheritance.
- 894f5dea76e1 13.0 landed
- 50289819230d 14.0 landed
- e22e29c258a1 10.15 landed
- d9253df12e4c 12.5 landed
- 37681d7e942e 9.6.20 landed
- 3737965249cd 11.10 landed
- 21f8b1811ac1 9.5.24 landed