Andres Freund <and...@anarazel.de> writes: > On 2021-04-18 11:29:42 -0400, Tom Lane wrote: >> I'm not sure that an error in this direction is all that much more >> problematic than the other direction. If it's okay to claim that >> indexes need to be rebuilt when they don't really, then we could just >> drop this entire overcomplicated infrastructure and report that all >> indexes need to be rebuilt after any collation version change.
> That doesn't ring true to me. There's a huge difference between needing > to rebuild all indexes, especially primary key indexes which often are > over int8 etc, and unnecessarily needing to rebuild indexes doing > comparatively rare things. It would not be that hard to exclude indexes on int8, or other cases that clearly have zero collation dependencies. And I think I might have some faith in such a solution. Right now I have zero faith that the patch as it stands gives trustworthy answers. I think that the real fundamental bug is supposing that static analysis can give 100% correct answers. Even if it did do so in a given state of the database, consider this counterexample: create type myrow as (f1 int, f2 int); create table mytable (id bigint, r1 myrow, r2 myrow); create index myindex on mytable(id) where r1 < r2; alter type myrow add attribute f3 text; myindex is recorded as having no collation dependency, but that is now wrong. regards, tom lane