Let's drop the meta-discussions and cut to the chase: given that we are
about to re-enable partial indexes, should we try to make EXTEND INDEX
work too, or just remove it?
The idea of EXTEND INDEX is to allow replacement of a partial index's
predicate. However, the implementation only supports weakening the
predicate, ie, it can only add tuples to the index not remove them.
The index's predicate is actually turned into (old predicate OR new
predicate), which seems counterintuitive to me.
I am not sure that EXTEND INDEX is actually broken. I originally
thought that the new predicate would replace the old, which would be
wrong --- but I now see the OR-ing behavior in UpdateIndexPredicate, so
it's not necessarily busted. The question is whether the feature has
enough usefulness to be worth supporting and documenting forevermore.
You can accomplish the same things, and more, by dropping the index and
building a new one; what's more, at least in the btree case building a
new one is likely to be much faster (the EXTEND code has to do retail
insertion, not a SORT-based build).
So, is it worth expending any effort on EXTEND INDEX? It seems to me
that it's a fair amount of code bulk and complexity for very very
marginal return. I'd like to simplify the index AM API by getting
rid of the concept.
regards, tom lane
