Re: BUG #15865: ALTER TABLE statements causing "relation already exists" errors when some indexes exist

I wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> commit e76de886157b7f974d4d247908b242607cfbf043
>> Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>> AuthorDate: Wed Jun 12 12:29:24 2019 -0400
>> CommitDate: Wed Jun 12 12:29:39 2019 -0400
>> Fix ALTER COLUMN TYPE failure with a partial exclusion constraint.

> Yeah, obviously I fat-fingered something there. Looking ...

Sigh ... so the answer is that I added the cleanup code (lines
10831..10864 in HEAD) in the wrong place. Putting it in
ATExecAlterColumnType is wrong because that gets executed potentially
multiple times per ALTER command, but I'd coded the cleanup assuming
that it would run only once. So we can end up with duplicate entries
in the changedIndexDefs list.

The right place to put it is in ATPostAlterTypeCleanup, of course.
(I think we could eliminate the changedIndexDefs list altogether and
just build the index-defining commands in the loop that uses them.)

This is a pretty embarrassing bug, reinforcing my hindsight view
that I was firing on very few cylinders last week. It basically
means that any ALTER TABLE that tries to alter the type of more than
one column is going to fail, if any but the last such column has a
dependent plain (non-constraint) index. The test cases added by
e76de8861 were oh so close to noticing that, but not close enough.

I'll go fix it, but do we need to consider a near-term re-release?

regards, tom lane