> 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.
We don't let people add columns to an existing index so I don't see why
we should have EXTEND INDEX unless index twiddling is more common with
partial indexes.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026