From: | Graeme <graeme(at)gemmill(dot)name> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_update and encoding |
Date: | 2023-09-12 14:56:46 |
Message-ID: | 54131f54-2118-414e-9405-8ae4b1d0c56f@gemmill.name |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 12/09/2023 15:52, Adrian Klaver wrote:
> On 9/12/23 04:49, Graeme wrote:
>> Preparing to use pg_update, I used initdb to create the new
>> pgsql/data, but pg_update has exited with
>
> I'm guessing that is actually pg_upgrade:
>
> https://www.postgresql.org/docs/current/pgupgrade.html
>
>>
>> encodings for database "template1" do not match: old "UTF8", new
>> "SQL_ASCII"
>>
>> Should I delete pgsql/data and re-create with initdb -E "UTF8"?
>
> Yes for two reasons:
>
> 1) The upgrade will not happen.
>
> 2) From here:
>
> https://www.postgresql.org/docs/current/multibyte.html
>
> "The SQL_ASCII setting behaves considerably differently from the other
> settings. When the server character set is SQL_ASCII, the server
> interprets byte values 0–127 according to the ASCII standard, while
> byte values 128–255 are taken as uninterpreted characters. No encoding
> conversion will be done when the setting is SQL_ASCII. Thus, this
> setting is not so much a declaration that a specific encoding is in
> use, as a declaration of ignorance about the encoding. In most cases,
> if you are working with any non-ASCII data, it is unwise to use the
> SQL_ASCII setting because PostgreSQL will be unable to help you by
> converting or validating non-ASCII characters."
>
>>
>> Thanks,
>>
>> Graeme
>>
>
Thanks, done. Data now accessible
Graeme
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2023-09-12 14:57:33 | Re: Upgrade problem |
Previous Message | Adrian Klaver | 2023-09-12 14:52:12 | Re: pg_update and encoding |