Re: Collation versioning - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Collation versioning
Date
Msg-id b4ae8ef0-3a32-0f9a-576b-8f53ddbdc56d@2ndquadrant.com
Whole thread Raw
In response to Re: Collation versioning  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Collation versioning
List 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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Include application_name in "connection authorized" logmessage
Next
From: David Rowley
Date:
Subject: Some incorrect comments and out-dated README from run-time pruning