Re: pg_update and encoding

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

In response to

Browse pgsql-general by date

  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