Message-ID: <2b9c6c1f-d5fc-cc29-c387-95abb815d12d@yandex.ru>
Date: Sun, 26 Nov 2023 19:38:49 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: WIP: libpq: add a possibility to not send D(escribe) when
 executing a prepared statement
Content-Language: en-US
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: pgsql-hackers@lists.postgresql.org
References: <82c438b4-d91c-9009-65fc-593124d5a277@yandex.ru>
 <6E9981D0-F66B-4102-8D6E-E85C7F2BD77B@yandex-team.ru>
From: Ivan Trofimov <i.trofimow@yandex.ru>
In-Reply-To: <6E9981D0-F66B-4102-8D6E-E85C7F2BD77B@yandex-team.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/2b9c6c1f-d5fc-cc29-c387-95abb815d12d%40yandex.ru>
Precedence: bulk

>> 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.