On Tue, Jul 2, 2019 at 9:19 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2019-07-01 22:46, Alvaro Herrera wrote:
> > On 2019-Jul-02, Thomas Munro wrote:
> >> On Tue, Jul 2, 2019 at 8:34 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> >>> Even if that's just me being delusional, I'd still prefer Alvaro's
> >>> approach to have distinct switches for each collation system.
> >>
> >> Makes sense. But why use the name "glibc" in the code and user
> >> interface? The name of the collation provider in PostgreSQL is "libc"
> >> (for example in the CREATE COLLATION command), and the problem applies
> >> no matter who makes your libc.
> >
> > Makes sense. "If your libc is glibc and you go across an upgrade over
> > version X, please use --include-rule=libc-collation"
>
> I think it might be better to put the logic of what indexes are
> collation affected etc. into the backend REINDEX command. We are likely
> to enhance the collation version and dependency tracking over time,
> possibly soon, possibly multiple times, and it would be very cumbersome
> to have to keep updating reindexdb with this. Moreover, since for
> performance you likely want to reindex by table, implementing a logic of
> "reindex all collation-affected indexes on this table" would be much
> easier to do in the backend.
That's a great idea, and would make the parallelism in reindexdb much
simpler. There's however a downside, as users won't have a way to
benefit from index filtering until they upgrade to this version. OTOH
glibc 2.28 is already there, and a hypothetical fancy reindexdb is far
from being released.
