libpqxx: New `exec_prepared` and `exec_params` don't support runtime variable argument lists
Unless I’m missing something, the old prepared followed by exec methods (as we use here and here) no longer support the case where we don’t know how many parameters we need until runtime.
I’m looking at the APIs at these two locations:
- https://github.com/jtv/libpqxx/blob/master/include/pqxx/transaction_base.hxx#L284
- https://github.com/jtv/libpqxx/blob/master/include/pqxx/transaction_base.hxx#L347
What’s the intended method for doing this now? I’m looking at current HEAD of master. (ah, found something, see below)
We’ve been used prepared statements for this, but actually for most of our use cases it’d probably be better to use exec_params method.
What I think I really need is something with a function signature like this:
template<typename Iter, typename Func>
result exec_params(std::string_view query, Iter begin, Iter end, Func transform);
template<typename Iter, typename Func>
result exec_prepared(std::string_view query, Iter begin, Iter end, Func transform);
Hopefully it’s possible to do something with string_view rather than c_str for the return type from the transform, but for that to work I believe you’ll actually need to expect transform to return std::optional<std::string_view>.
I’ve just found #75 which also talks about this, so I’ll have a go at that solution. The only way I found out about dynamic_params was to look at the commit referenced in the issue 😃 Without the transform function it’s going to cost several allocations to do the data transform I need 😦
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 47 (47 by maintainers)
Commits related to this issue
- Optiomnal accessor for `dynamic_params`. Hopefully this will help with #184, in avoiding a buffering step for the parameters. — committed to jtv/libpqxx by jtv 5 years ago
- Allow modifying accessor in `make_dynamic_params`. This should help with one part of #184. When you `make_dynamic_params`, you can now pass a non-const container reference and an accessor which take... — committed to jtv/libpqxx by jtv 5 years ago
- Specialise `string_traits` for `string_view`. (Also `zview`, of course.) There can be no `from_string` in this specialisation, because it would have nowhere to store its contents. But `from_string`... — committed to jtv/libpqxx by jtv 5 years ago
@KayEss I’ve prototyped a new class template,
str, for representing values asstd::string_viewand avoiding buffer allocation. Actually it starts with a kind of generalised version ofto_charswhich returns astd::string_view— which may or may not point to text inside the buffer you give it. Will try to get it intomastersoon, so you can have a look.