Re: Collation versioning

On Thu, Feb 13, 2020 at 09:44:40AM +1300, Thomas Munro wrote:
> On Thu, Feb 13, 2020 at 9:16 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> > On Wed, Feb 12, 2020 at 08:55:06PM +0100, Laurenz Albe wrote:
> > > I didn't study the patch in detail, but do I get it right that there will be no
> > > warnings about version incompatibilities with libc collations?
> >
> > No, libc is also be supported (including the default collation), as long as we
> > have a way to get the version.  Unfortunately, that means only linux/glibc.  I
> > think that there was some previous discussion to work around that limitation
> > for other systems, using some kind of hash of the underlying collation files,
> > as Peter mentioned recently, but that's not part of this patchset.
>
> Yeah, this is about the cataloguing infrastructure part, to get the
> model and mechanisms right.  To actually get version information from
> the underlying collation provider, there will need to be a series of
> per-OS projects.  For glibc right now, it's done, but we just use the
> whole glibc version as a proxy (sadly we know this can give false
> positives and false negatives, but is expected to work a lot better
> than nothing).  I hope we can get a proper CLDR version out of that
> library one day.  For FreeBSD libc, I have patches, I just need more
> round tuits.  For Windows, there is
> https://commitfest.postgresql.org/27/2351/ which I'm planning to
> commit soonish, after some more thought about the double-version
> thing.  Then there is the "run a user-supplied script that gives me a
> version" concept, which might work and perhaps allow package
> maintainers to supply a script that works on each system.  Again,
> that'd be a separate project.

Thanks for working on that, it'll be great improvements!

> I guess there will probably always be
> some OSes that we can't get the data from so we'll probably always
> have to support "don't know" mode.

I realized this morning that I didn't add test to validate that we emit the
expected warnings in case of version mismatch.  While adding some, I found that
for the unknown versino, my code was actually testing the "versioning support
for that lib on that system is now supported" and not "you apparently upgraded
from pre-v13 with supported collation library versioning, and the version was
marked as unknown".  Attached v9 fixes the test to handle both cases.

I also added TAP regression tests for version mismatch checking in the
src/test/locale tests.  This subdirectory wasn't included by default, probably
because there was no "check" or "installcheck" target so building test-ctype
was pointless, it's now included by default.