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

Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> So I agree, that disabling the drop operation when a composite type has
> dependencies is not a harmless change. On the other hand, the code might be
> not ready to deal with the uniqueness assumption violated.

Well, corrupt indexes are a fact of life and probably always will be,
because collations are such an unpredictable mess. So if we have anyplace
that is straight out Assert'ing that uniqueness holds, I'd say that that
needs reconsideration. We need to try to turn it into a helpful error
message.

> #5  0x000055d3131e314f in ExceptionalCondition (
>     conditionName=conditionName(at)entry=0x55d313357b85 "next_index == nparts",
>     fileName=fileName(at)entry=0x55d313357887 "partbounds.c", lineNumber=lineNumber(at)entry=884) at assert.c:66

Hmm. I did not trace this down, but it doesn't look like it's exactly
connected to corrupt indexes.

regards, tom lane