Re: Re: [PATCH] To remove EXTEND INDEX

> 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