[Libpqxx-general] Unnamed prepared statements vs PQexecParams
Jeroen T. Vermeulen
jtv at xs4all.nl
Sat Oct 10 17:37:08 UTC 2009
On Wed, September 30, 2009 17:47, Trigve Siver wrote:
> Hi,
Hi Trigve,
> as stated in subject I have some "C++ design" problem with unnamed
> prepared statements. Till now I was using "Session" (pqxx::connection
> wrapper) objects when preparing statements, executing statements, ... .
> (Transactions (pqxx::work) were created only in functions that used
> "Session" objects and weren't needed to be created outside the functions).
> But now I can create external "Transaction" object and need to execute
> some commands trough it. So I was thinking in changing my API like that:
> Function that need to create prepared statements will need only "Session"
> object, the one that execute statements will need only "Transaction"
> object. But as some time ago was suggested I've been using unnamed
> prepared statements as workaround for PQexecParams missing. But now I'll
> have to pass also "Session" object because only there I can create prepare
> statements, which isn't good.
Why not just pass the transaction object but get its connection reference
by calling conn()?
> I think this could be solved to by implementing PQexecParams
> (pqxx::prepare::invocation-style API would be fine) inside transaction
> class. I can handle this task if there will be interface specified and so.
> Second workaround could be to add some functions to pqxx transaction
> classes for creating ONLY unnamed prepared statements.
I'd be very pleased if you have time to work on that. The API would have
to reuse as much as possible from the prepared-statements API; ideally the
only difference would be a different "exec" function that takes a query
instead of a prepared-statement name. Coming up with a clean, elegant
solution for that may be hard though.
Jeroen
More information about the Libpqxx-general
mailing list