Re: Move defaults toward ICU in 16?

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

In response to

Responses

Browse pgsql-hackers by date

  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