Re: Collation versioning

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Collation versioning
Date: 2018-09-06 19:01:14
Message-ID: b7ce31bb-dfe5-c689-06c4-3a8536f73e6a@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/09/2018 23:18, Thomas Munro wrote:
> On Wed, Sep 5, 2018 at 12:10 PM Christoph Berg <myon(at)debian(dot)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?

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.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-09-06 19:14:51 Allow parallelism for deferrable serializable txns
Previous Message Michael Paquier 2018-09-06 18:56:27 Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace