Dmitriy Igrishin wrote:
> Sent: Thursday, June 20, 2013 5:09 PM
> To: PostgreSQL Hackers
> Subject: [HACKERS] Frontend/backend protocol improvements proposal (request).
>
> Hackers,
>
> While developing a C++ client library for Postgres I felt lack of extra
> information in command tags in the CommandComplete (B) message
> for the following commands:
> PREPARE;
> DEALLOCATE;
> DECLARE;
> CLOSE;
> LISTEN;
> UNLISTEN;
> SET;
> RESET.
> Namely, for example, users of my library can prepare statements by using
> protocol directly or via PREPARE command. Since the protocol does not
> supports prepared statement deallocation, I wrote a wrapper over DEALLOCATE
> command. The library knows about all prepared statements and
> invalidates them automatically when user performs deallocate() wrapper.
> But users can go with DEALLOCATE command directly and in these cases
> I need to query the database to get the list of currently prepared statements
> whenever CommandComplete message with DEALLOCATE command tag
> is consumed. Moreover, I need to do it *synchronously* and this breaks
> asynchronous API.
> I propose to include name of the object in the CommandComplete (B)
> message for the above commands.
That would be a change in the protocol, so it's not likely to happen
soon. There is a page where proposed changes to the wire protocol
are collected: http://wiki.postgresql.org/wiki/Todo#Wire_Protocol_Changes
It seems like bad design to me to keep a list of prepared statements
on the client side when it is already kept on the server side
(accessible with the pg_prepared_statements view).
What's wrong with the following:
If the user wants to deallocate an individual prepared statement,
just send "DEALLOCATE <statement name>" to the server. If the
statement does not exist, the server will return an error.
If the user wants to deallocate all statements, just send
"DEALLOCATE ALL".
Why do you need to track prepared statements on the client side?
Yours,
Laurenz Albe