Dmitriy Igrishin wrote:
Since there can be only one unnamed prepared statement per
session, there should be only one such object per connection.
It should not get deallocated; maybe it could be private to the
connection, which only offers a parseUnnamed and executeUnnamed
mathod.
More
Dmitriy Igrishin wrote:
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
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
I'm moving this discussion to -general.
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 [...]
for the following commands:
It seems like bad design to me to keep a list of prepared
Albe Laurenz laurenz.a...@wien.gv.at writes:
Why do you need to track prepared statements on the client side?
The proposed change would fail to allow that anyway; consider the
possibility of a server-side function doing one or more PREPAREs or
DEALLOCATEs. The command tag would be completely
2013/6/24 Tom Lane t...@sss.pgh.pa.us
Albe Laurenz laurenz.a...@wien.gv.at writes:
Why do you need to track prepared statements on the client side?
The proposed change would fail to allow that anyway; consider the
possibility of a server-side function doing one or more PREPAREs or
