Re: Collation versioning

Julien Rouhaud <rjuju123@gmail.com>

From: Julien Rouhaud <rjuju123@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>, Thomas Munro <thomas.munro@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Douglas Doole <dougdoole@gmail.com>, Christoph Berg <myon@debian.org>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2020-09-16T17:40:40Z
Lists: pgsql-hackers
On Tue, Sep 15, 2020 at 2:26 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2020-09-08 16:45, Julien Rouhaud wrote:
> > I usually agree with that approach, I'm just afraid that getting a consensus on
> > the best way to do that will induce a lot of discussions, while this is
> > probably a corner case due to general usage of hash and bloom indexes.
> >
> > Anyway, in order to make progress on that topic I attach an additional POC
> > commit to add the required infrastructure to handle this case in
> > v29-0001-Add-a-new-amnostablecollorder-flag-in-IndexAmRou.patch.
>
> I'm confused now.  I think we had mostly agreed on the v28 patch set,
> without this additional AM flag.  There was still some discussion on
> what the AM flag's precise semantics should be.  Do we want to work that
> out first?

That was my understanding too, but since Michael raised a concern I
wrote some initial implementation for that part.  I'm assuming that
this new flag will raise some new discussion, and I hope this can be
discussed later, or at least in parallel, without interfering with the
rest of the patchset.

> Btw., I'm uneasy about the term "stable collation order".  "Stable" has
> an established meaning for sorting.  It's really about whether the AM
> uses collations at all, right?

Well, at the AM level I guess it's only about whether it's using some
kind of sorting or not, as the collation information is really at the
opclass level.  It makes me realize that this approach won't be able
to cope with an index built using (varchar|text)_pattern_ops, and
that's probably something we should handle correctly.



Commits

  1. Doc: Document known problem with Windows collation versions.

  2. Add collation versions for FreeBSD.

  3. Tolerate version lookup failure for old style Windows locale names.

  4. Track collation versions for indexes.

  5. Add pg_depend.refobjversion.

  6. Remove pg_collation.collversion.

  7. Fix the MSVC build for versions 2015 and later.

  8. Add collation versions for Windows.

  9. Implement type regcollation

  10. Use libc version as a collation version on glibc systems.

  11. Make type "name" collation-aware.