Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently
Date
Msg-id 3332642.1679943981@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently
List pgsql-bugs
Alexander Lakhin <exclusion@gmail.com> writes:
> 27.03.2023 21:20, Tom Lane wrote:
>> 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);

Sure, but there you already have a partition.  If you only had "tbl"
then there would be no stored partition bounds.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently
Next
From: PG Bug reporting form
Date:
Subject: BUG #17873: Empty JSONB array is ordered before all other JSONB values