| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
| Cc: | Christoph Berg <myon(at)debian(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Collation versioning |
| Date: | 2018-09-27 21:19:26 |
| Message-ID: | b4ae8ef0-3a32-0f9a-576b-8f53ddbdc56d@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-09-27 21:20:18 | Some incorrect comments and out-dated README from run-time pruning |
| Previous Message | Peter Eisentraut | 2018-09-27 21:15:13 | Re: [PATCH] Include application_name in "connection authorized" log message |