From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
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 18:20:13 |
Message-ID: | 3267914.1679941213@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.)
[ 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2023-03-27 19:00:00 | Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently |
Previous Message | Alexander Lakhin | 2023-03-27 18:00:00 | Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently |