On Fri, Jul 05, 2019 at 07:25:41PM +0200, Julien Rouhaud wrote:
> On Fri, Jul 5, 2019 at 6:16 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>> Isn't that also the case for your proposal? We are not going to release
>> a new reindexdb before a new REINDEX.
>
> Sure, but my point was that once the new reindexdb is released (or if
> you're so desperate, using a nightly build or compiling your own), it
> can be used against any previous major version. There is probably a
> large fraction of users who don't perform a postgres upgrade when they
> upgrade their OS, so that's IMHO also something to consider.
I think that we need to think long-term here and be confident in the
fact we will still see breakages with collations and glibc, using a
solution that we think is the right API. Peter's idea to make the
backend-aware command of the filtering is cool. On top of that, there
is no need to add any conflict logic in reindexdb and we can live with
restricting --jobs support for non-index objects.
--
Michael
