Dmitriy Igrishin wrote:
>>>> While developing a C++ client library for Postgres I felt lack of extra
>>>> information in command tags in the CommandComplete (B) message [...]
>>> 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?
> Thats great, but there is a some problem -- the *another* statement with the same
> name (and moreover with same parameters!) can be prepared after deallocating.
> And this can result in bugs. So, the client-side allocated "pointer to the remote
> statement" must be invalidated immediatly after deallocating.
I understand the problem now.
I pondered a bit over your design, and I came up with a different
idea how to represent prepared statements in a C++ library.
First, a prepared statement is identified by its name.
To make the relationship between a PreparedStatement object
and the PostgreSQL prepared statement unique, I suggest that
the prepared statement name should not be exposed to the
library user. It should be a private property that is
set in the initializer in a unique fashion (for example, it
could be a string representation of the memory address
of the object).
That way, there can never be a name collision. That should take
care of the problem.
Of course somebody could find out what the statement name is and
manually issue a DEALLOCATE, but that would only cause future
use of the prepared statement to fail with an error, which I
think is ok.
Also, if somebody uses SQL PREPARE to create a prepared statement
whose name collides with one of the automatically chosen names,
they get what they deserve in my opinion.
It might be useful to warn users.
I also wouldn't provide a deallocate() method. A deallocated
prepared statement is useless. I think that it would be more
logical to put that into the destructor method.
If somebody wants to get rid of the prepared statement
ahead of time, they can destroy the object.
Does that make sense?
Yours,
Laurenz Albe
