Horton

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>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: tom@intevation.de
Cc: pgsql-bugs@lists.postgresql.org
Date: 2020-02-21T23:33:31Z
Lists: pgsql-bugs

Attachments

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 think this is basically another instance of the ALTER TABLE issues
I recently fixed: doing this sort of transformation at parse time is
fundamentally broken.  We should refrain from trying to import the LIKE
table's indexes etc. until after MergeAttributes has done its work, and
most likely ought to just punt LIKE transformation into DefineRelation
altogether.  That's probably too big a change to consider back-patching,
unfortunately.

For future reference, there are some test cases in create_table_like.sql
that come oh so close to exposing these issues.  But not close enough.
See attached test-case patch (with wrong results).

			regards, tom lane

Commits

  1. Use the properly transformed RangeVar for expandTableLikeClause().

  2. Fix handling of CREATE TABLE LIKE with inheritance.