|From:||Julien Rouhaud <rjuju123(at)gmail(dot)com>|
|To:||Thomas Munro <thomas(dot)munro(at)gmail(dot)com>|
|Cc:||Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Douglas Doole <dougdoole(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Collation versioning|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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(at)gmail(dot)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.
|Next Message||曾文旌 (义从)||2020-02-15 09:56:42||Re: [Proposal] Global temporary tables|
|Previous Message||Pavel Stehule||2020-02-15 08:05:01||Re: proposal: schema variables|