| From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
|---|---|
| To: | 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-23 18:21:21 |
| Message-ID: | 589f2863-f7a8-3519-533a-f5751513823b@aklaver.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 6/23/22 10:11, Adrian Klaver wrote:
> On 6/23/22 00:37, Tomas Pospisek wrote:
>> On 22.06.22 22:18, Tomas Pospisek wrote:
>>> On 22.06.22 21:25, Adrian Klaver wrote:
>>>> On 6/22/22 12:17, Tomas Pospisek wrote:
>
>>
>> So I used both pg_dump and pg_restore from the newer machine. Result
>> is still the same. So I'll use Tom Lane's suggestion too and fix the
>> 'UTF-8' spelling in the dump file:
>
> Not sure why that is necessary? Is seems this is low hanging fruit that
> could dealt with by the equivalent of lower('en_US.UTF-8') =
> lower('en_US.utf-8').
Well that was clear as mud. My point was that I don't see why the end
user should have to do this when it could be handled internally in the
pg_restore code.
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Verite | 2022-06-23 21:14:27 | Re: Differences in Escaped bytea's when creating a plain pg_dump |
| Previous Message | Adrian Klaver | 2022-06-23 17:11:21 | Re: ERROR: new collation (en_US.UTF-8) is incompatible with the collation of the template database (en_US.utf-8) |