Message-ID: <852dee881b6cc82b9d4b51d69d48c415e2a87b4d.camel@cybertec.at>
Subject: Re: PQexecPrepared() question
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Igor Korot <ikorot01@gmail.com>, "pgsql-generallists.postgresql.org"
	 <pgsql-general@lists.postgresql.org>
Date: Sat, 20 Dec 2025 07:24:47 +0100
In-Reply-To: <CA+FnnTyYBNwbzFs5GqO+SMg3g60jPTsnmFwTV=_s_YboGo-68A@mail.gmail.com>
References: 
	<CA+FnnTygjVvSmzTHnvteuL4KEC=0P_+mF8Kn84JtNGZWUGxpUA@mail.gmail.com>
	 <2547700.1765940917@sss.pgh.pa.us>
	 <CA+FnnTxO6kam9=mRonvsnUA1OxJxdDdQsj+ubdgFNNb9b3WMPQ@mail.gmail.com>
	 <9a0ce31a49f149d8d982d2b359095560655f781e.camel@cybertec.at>
	 <CA+FnnTzE34VJWR7xkymaKEwXiiQ8j3o03m0+qcQsRr2JkRQLwQ@mail.gmail.com>
	 <ebaca1066dfdf567d158fc48dce86a6fcc132988.camel@cybertec.at>
	 <CA+FnnTz5tcJEL12ir1nxe9q75rxaAdfBtcFUNiD4R5gW_JR23A@mail.gmail.com>
	 <CA+FnnTyYBNwbzFs5GqO+SMg3g60jPTsnmFwTV=_s_YboGo-68A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/852dee881b6cc82b9d4b51d69d48c415e2a87b4d.camel%40cybertec.at>
Precedence: bulk

On Fri, 2025-12-19 at 20:10 -0800, Igor Korot wrote:
> > > > What is =E2=80=9Cclientencoding in this case?
> > >=20
> > > - if PGCLIENTENCODING is set in the environment of the client executa=
ble, that
> >=20
> > No it is not.
> >=20
> > > - otherwise, if "client_encoding" is set on the server, that
>=20
> I just checked the postgres.conf.
>=20
> This file does not have any client_encoding.
>=20
> > > - otherwise, SQL_ASCII
>=20
> Which means that this is an encoding that will be used.

You can verify that with the SQL statement "SHOW client_encoding"
in your sample program.

> But then I don=E2=80=99t understand anything.
>=20
> The code I posted above worked fine on SELECT, but INSERT failed.
>=20
> If the SQL_ASCII is the encoding used both operations should fail. Or bot=
h succeeds.
>=20
> Could someone explain what happened?

SQL_ASCII as client encoding means that no conversion will take place.

Still, the database encoding (I suspect UTF8) will govern what can be store=
d
in the database.  Anything that is not valid UTF-8 will be rejected.

A SELECT will never cause an error - the client will just receive data
in UTF-8.

Yours,
Laurenz Albe