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 3267914.1679941213@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  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-bugs
Alexander Lakhin <exclusion@gmail.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.)

[ thinks some more... ] I guess there's the corner case where we
replace, say, a hashable type with a non-hashable one and thereby
break decisions about whether PARTITION BY HASH is allowable.
That's kind of a stretch.  But find_composite_type_dependencies
currently rejects partitioned tables, so we're not taking away any
functionality if we continue to forbid that.

            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: Alexander Lakhin
Date:
Subject: Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently