Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail

Michael Paquier <michael@paquier.xyz> writes:
> I have done some work on that, and for now I am finishing with the
> attached.  This takes the approach of updating BuildIndexInfo() so as
> the optimizations for the planner are not done.

This seems like a really bad idea.

As you have it, whether the relcache contains optimized or unoptimized
expressions will be basically chance, depending on which sort of call
happened first after the last cache flush.  That will break things,
because for most use-cases it's *not* optional to apply
eval_const_expressions.

Even without that, changing the APIs of the functions you've touched
here seems pretty invasive.

I think the correct fix is to nuke the code in REINDEX CONCURRENTLY that
thinks it should use any of this infrastructure to fetch the existing
index properties, and just have it read the catalog directly instead.

			regards, tom lane