Re: PQexecPrepared() question

Поиск
Список
Период
Сортировка
От Igor Korot
Тема Re: PQexecPrepared() question
Дата
Msg-id CA+FnnTxOzSBj-YZmsCcQ-2khU4pG=O1C5qdX8huyTwvRXHA9qg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PQexecPrepared() question  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: PQexecPrepared() question
Список pgsql-general
Hi, Lauren’z,


On Fri, Dec 19, 2025 at 10:24 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Fri, 2025-12-19 at 20:10 -0800, Igor Korot wrote:
> > > > What is “clientencoding in this case?
> > >
> > > - if PGCLIENTENCODING is set in the environment of the client executable, that
> >
> > No it is not.
> >
> > > - otherwise, if "client_encoding" is set on the server, that
>
> I just checked the postgres.conf.
>
> This file does not have any client_encoding.
>
> > > - otherwise, SQL_ASCII
>
> 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.


Thx, will check.



> But then I don’t understand anything.
>
> The code I posted above worked fine on SELECT, but INSERT failed.
>
> If the SQL_ASCII is the encoding used both operations should fail. Or both succeeds.
>
> 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 stored
in the database.  Anything that is not valid UTF-8 will be rejected.

Rejected how?



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

And then what?

I’ll check the encoding and report back..

Thank you.



Yours,
Laurenz Albe

В списке pgsql-general по дате отправления: