| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Tomas Pospisek <tpo2(at)sourcepole(dot)ch>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: ERROR: new collation (en_US.UTF-8) is incompatible with the collation of the template database (en_US.utf-8) |
| Date: | 2022-06-24 14:36:28 |
| Message-ID: | 354889.1656081388@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> There are also cases where on one system the locale is spelled
> xx_YY.UTF8 and on another xx_YY.UTF-8. If we start adjusting for case,
> should we adjust for this as well? What other cases are there?
> So this would need a bit more research.
Yeah. I would tend to define it as "if the locale names both end
in dot followed by a recognizable encoding name, then (a) make
sure that the encoding values are the same, then (b) strip off
the dot and encoding before comparing the rest". We already have
code to look up encoding names, and it handles all these variants.
So this doesn't seem like it should take much new code, though
maybe some refactoring would be needed to make the lookup code
available where this check is happening.
I'm not personally very excited about this, but if someone wanted
to prepare a patch...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ninad Shah | 2022-06-24 16:56:44 | Re: Automatic autovacuum to prevent wraparound - PG13.5 |
| Previous Message | Mahendrakar, Prabhakar - Dell Team | 2022-06-24 13:03:57 | RE: Postgresql error : PANIC: could not locate a valid checkpoint record |