Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes

> Wouldn't it make more sense to just ignore invalid indexes and not build
> anything at all for them?

I followed what REPACK/VACUUM FULL does - it similarly rebuilds
invalid indexes, shouldn't we keep the two consistent?

And by skipping you mean that we should create an empty index instead
when repack sees an invalid index?

One argument for that is that the current code only handles unique
constraint violation, while there's a preexisting issue that these
commands all fail with other index failures, except REINDEX TABLE
CONCURRENTLY, e.g.:

CREATE TABLE t (i int PRIMARY KEY, j int);
INSERT INTO t VALUES (1, 0), (2, 1);
CREATE INDEX CONCURRENTLY t_expr ON t ((1/j));

VACUUM FULL t;
CLUSTER t USING t_pkey;
REINDEX TABLE t;
ALTER TABLE t ALTER COLUMN j TYPE bigint;
REINDEX TABLE CONCURRENTLY t;   -- only this works

If we would skip all invalid indexes, that could solve this too
(except for the ALTER TABLE).

I wanted to raise this issue separately, as this seems to be
preexisting in earlier versions, not a new bug. (and a more complex
discussion than "repack and repack (concurrently) should behave
similarly")