Post by Dragon MasterI believe, after studying the code, that the answer is no, and the
pqxx::pipeline::query_id
pqxx::prepare::invocation::insert(pqxx::pipeline &pipe);
Indeed, the answer is no, but I believe it could be made to work. A
solution I toyed with once upon a time, but never implemented, was to
isolate an internal layer of abstraction that, essentially, pipelined
everything that libpqxx does internally. Another approach would be to
adapt any individual feature (such as prepared statements) to interact
with pipelines as needed.
For the immediate problem of using prepared statements inside a pipeline
though, you can use the workaround in my previous post.
For the record, I would expose a combination of prepared statements and
pipelines in the pipeline API, not the prepared-statements API. So
you'd say "pipe.insert(conn.prepared("foo"))" rather than
"conn.prepared("foo").insert(pipe)."
Post by Dragon MasterDoes that clarify my question? So the question then becomes, is it
feasible to implement such a method? Without digging into the guts of
gate::connection_prepare_invocation(), I couldn't say.
I think it is feasible and it might be nice to have this work. There
are some limitations: libpq probably won't let us prepare or unprepare a
statement while a pipeline has statements in progress. (In truth
libpqxx can also generate PREPARE statements, to support ancient libpq
versions, but that's code I would dearly like to be rid of).
The simplest solution to that is to wait and serialize whenever a
statement needs to be prepared or deallocated; a more advanced solution
would defer it until a suitable time. And with recent libpq versions,
it could even prepare statements asynchronously.
Jeroen