From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Move defaults toward ICU in 16? |
Date: | 2023-02-17 20:36:05 |
Message-ID: | 3bf6b5517033947c134ed1ba9a325179a608bfd1.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2023-02-17 at 10:09 -0800, Andres Freund wrote:
> -1. That's just going to cause pain one major version upgrade further
> down the
> line. Why would we want to incur that pain?
OK, we can just always do the fixup as long as the old one is libc and
the new one is ICU. I'm just trying to avoid this becoming a general
mechanism to fix up an incompatible new cluster.
> > There's already a check that the new cluster is empty, so I think
> > it's
> > safe to hack the pg_database locale fields.
>
> I don't think we need to, we do issue the CREATE DATABASEs. So we
> just need to
> make sure that includes the collation provider info, and the proper
> template
> database, in pg_upgrade mode.
We must fixup template1/postgres in the new cluster (change it to libc
to match the old cluster), because any objects existing in those
databases in the old cluster may depend on the default collation. I
don't see how we can do that without updating pg_database, so I'm not
following your point.
(I think you're right that template0 is optional; but since we're
fixing up the other databases it would be less surprising if we also
fixed up template0.)
And if we do fixup template0/template1/postgres to match the old
cluster, then CREATE DATABASE will have no issue.
--
Jeff Davis
PostgreSQL Contributor Team - AWS
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-02-17 20:37:59 | Re: pg_init_privs corruption. |
Previous Message | Alvaro Herrera | 2023-02-17 20:35:12 | Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error |