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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: tom(at)intevation(dot)de
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16272: Index expression can refer to wrong attributes if index is created via CREATE TABLE LIKE
Date: 2020-02-21 23:33:31
Message-ID: 6861.1582328011@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

Attachment Content-Type Size
tests-for-incorrect-LIKE-column-mapping.patch text/x-diff 3.7 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michail Nikolaev 2020-02-22 20:08:45 Re: BUG #16108: Colorization to the output of command-line has unproperly behaviors at Windows platform
Previous Message duvall 2020-02-21 19:45:21 Re: CREATE TABLE IF NOT EXISTS fails with privilege exception when table exists