Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently
Date: 2023-03-27 19:00:00
Message-ID: 67cb509e-93c7-1c7b-2388-d7e00277b344@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

27.03.2023 21:20, Tom Lane wrote:
> Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
>> Yes, I think something like that can resolve the issue.
>> But I would also note that the problem is not with indexes only, but also
>> with "... partition by list(comp_type_value)", for example.
> Hmm ... really? I'd just concluded that a partitioned table is okay
> as long as it doesn't yet have any partitions. Even if the modified
> type is a partitioning column, there's no structure yet that could
> depend on the contents of the type. (If it does have partitions,
> we'll fail when we get to one of those.)

The following query leads to a failure on showing a partition definition:
CREATE TABLE tbl(a int, b int) PARTITION BY LIST ((tbl));
CREATE TABLE tblp PARTITION OF tbl FOR VALUES IN ('(2,4)');
ALTER TABLE tbl ALTER COLUMN a TYPE char(5);
\d+ tbl
(The effect depends on the values specified.)
It's not exactly the dependency issue but still is related to altering
a composite type.

Best regards,
Alexander

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-03-27 19:06:21 Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently
Previous Message Tom Lane 2023-03-27 18:20:13 Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently