Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jul 23, 2021 at 2:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> However, for the reasons I explained before, there are no general-purpose
>> cases where we can skip an index build on a type-changed column, so
>> there is no place to insert a similar hack for the timestamp[tz] case.
> Wouldn't the hack just go into CheckIndexCompatible()?
Oh! I went looking for code to skip rebuilding indexes during ALTER TYPE,
but I guess I looked in the wrong place, because I missed that somehow.
> You seemed to think my previous comments about comparing opfamilies
> were hypothetical but I think we actually already have the
> optimization Peter wants, and it just doesn't apply in this case for
> lack of hacks.
Hmm. Note that what this is checking for is same operator *class* not
same operator family (if it were doing the latter, Peter's case would
already work). I think it has to do that. Extending my previous
thought experiment about an unsigned integer type, if someone were to
invent one, it would make a lot of sense to include it in integer_ops,
and then the logic you suggest is toast. (Obviously, the cross-type
comparison operators you'd need to write would have to be careful,
but you'd almost certainly wish to write them anyway.)
Given that we require the non-cross-type members of an opclass to be
immutable, what this is actually doing may be safe. At least I can't
construct a counterexample after five minutes' thought. On the other
hand, I'm also a bit confused about how it ever succeeds at all.
If we've changed the heap column's type, it should not be using the
same opclass anymore (unless the opclass is polymorphic, but that
case is rejected too). I'm suspicious that this is just an expensive
way of writing "we can only preserve indexes that aren't on the
column that changed type".
regards, tom lane