On Fri, Sep 28, 2018 at 9:19 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> 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.
If that turns out to be impractical, I guess the "status quo" option
would be to add datcollprovider to pg_database. If we switch to
per-index version tracking as I proposed upthread (dropping
collversion), then the
where-do-we-stick-the-default-collation's-version problem goes away.
--
Thomas Munro
http://www.enterprisedb.com