Re: WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement

From: Ivan Trofimov <i(dot)trofimow(at)yandex(dot)ru>
To: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement
Date: 2023-11-26 16:38:49
Message-ID: 2b9c6c1f-d5fc-cc29-c387-95abb815d12d@yandex.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> In a presumably very common case of repeatedly executing the same statement, this leads to
>> both client and server parsing/sending exactly the same RowDescritpion data over and over again.
>> Instead, library user could acquire a statement result RowDescription once (via PQdescribePrepared),
>> and reuse it in subsequent calls to PQexecPrepared and/or its async friends.
> But what if query result structure changes? Will we detect this error gracefully and return correct error?

Afaik changing prepared statement result structure is prohibited by
Postgres server-side, and should always lead to "ERROR: cached plan
must not change result type", see src/test/regress/sql/plancache.sql.

So yes, from the libpq point of view this is just an server error, which
would be given to the user, the patch shouldn't change any behavior here.

The claim about this always being a server-side error better be
reassured from someone from the Postgres team, of course.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-11-26 17:13:45 Re: WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement
Previous Message Tom Lane 2023-11-26 16:35:19 Re: Missing docs on AT TIME ZONE precedence?