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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
