Re: Collation versioning - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Collation versioning
Date
Msg-id 4b76c6d4-ae5e-0dc6-7d0d-b5c796a07e34@2ndquadrant.com
Whole thread Raw
In response to Re: Collation versioning  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Collation versioning  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On 2018-09-05 23:18, Thomas Munro wrote:
> On Wed, Sep 5, 2018 at 12:10 PM Christoph Berg <myon@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)

After, um, briefly sleeping on this, I would like to go ahead with this.

There is ongoing work to make ICU available globally, and as part of
that I've also proposed a way to make the collation version tracking
work on a database level.

This here would be a useful piece on the overall picture.  Independent
of what becomes of the ICU effort, we could have glibc collation version
tracking completely working for PG13.

The only open question on this patch was whether it's a good version to
use.  I think based on subsequent discussions, there was the realization
that this is the best we can do and better than nothing.

In the patch, I would skip the configure test and just do

#ifdef __GLIBC__

directly.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP: Generic functions for Node types using generated metadata
Next
From: Tom Mercha
Date:
Subject: Re: Is querying SPITupleTable with SQL possible?