On Thu, Sep 6, 2018 at 12:01 PM Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 05/09/2018 23:18, Thomas Munro wrote: > > On Wed, Sep 5, 2018 at 12:10 PM Christoph Berg <m...@debian.org> wrote: > >>> So, it's not ideal but perhaps worth considering on the grounds that > >>> it's better than nothing? > >> > >> Ack. > > > > Ok, here's a little patch like that. > > > > postgres=# select collname, collcollate, collversion from pg_collation > > where collname = 'en_NZ'; > > collname | collcollate | collversion > > ----------+-------------+------------- > > en_NZ | en_NZ.utf8 | 2.24 > > (1 row) > > But wouldn't that also have the effect that glibc updates that don't > change anything about the locales would trigger the version > incompatibility warning?
Right. And likewise, a glibc update that does change some locales but not the locales that you are actually using will trigger false alarm warnings. The same goes for the ICU provider, which appears to return the same collversion for every collation, even though presumably some don't change from one ICU version to the next. I wonder if someone here knows how many "locales" packages have been released over the lifetime of (say) the current Debian stable distro, whether any LC_COLLATE files changed over those releases, and whether libc6 had the same MAJOR.MINOR for the whole lifetime. That is, even though they might have been through 2.19-17+blah, 2.19-18+blah, ... did they all report "2.19" and were the collations actually stable? If that's the case, I think it'd be quite good: we'd only raise the alarm after a big dist-upgrade Debian 8->9, or when doing streaming replication from a Debian 8 box to a Debian 9 box. > Also, note that this mechanism only applies to collation objects, not to > database-global locales. So most users wouldn't be helped by this approach. Yeah, right, that would have to work for this to be useful. I will look into that. -- Thomas Munro http://www.enterprisedb.com
