Horton

Re: Collation versioning

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Christoph Berg <myon@debian.org>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-09-27T21:19:26Z
Lists: pgsql-hackers 
On 16/09/2018 10:19, Thomas Munro wrote:
> 4.  After creating a new database, update that row as appropriate in
> the new database (!).  Or find some other way to write a new table out
> and switch it around, or something like that.  That is, if you say
> CREATE DATABASE foo LC_COLLATE = 'xx_XX', COLLATION_PROVIDER = libc
> then those values somehow get written into the default pg_collation
> row in the *new* database (so at that point it's not a simple copy of
> the template database).

I've been hatching this exact scheme since the very beginning, even
thinking about using the background session functionality to do this.
It would solve a lot of problems, but there is the question of exactly
how to do that "(!)" part.

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

Commits

  1. Doc: Document known problem with Windows collation versions.

  2. Add collation versions for FreeBSD.

  3. Tolerate version lookup failure for old style Windows locale names.

  4. Track collation versions for indexes.

  5. Add pg_depend.refobjversion.

  6. Remove pg_collation.collversion.

  7. Fix the MSVC build for versions 2015 and later.

  8. Add collation versions for Windows.

  9. Implement type regcollation

  10. Use libc version as a collation version on glibc systems.

  11. Make type "name" collation-aware.