Jeroen Vermeulen
Jeroen Vermeulen
I'm forming some answers to the questions. For example, I'm now leaning towards making all iteration and indexing return iterators, not `pqxx::row` or `pqxx::field`. If you wanted to keep the...
Well yes, of course - the change you asked for breaks compatibility.
I've got my laptop back, but unfortunately there was no chance to make a backup. There was a lot of incomplete work on these iterators on there. :-(
I think this might be a good thing to put on the list for libpqxx 8.0, and combine it with at least the preparation for #846.
It's been ages. But I've had some more time to think about it, and I think in libpqxx 8.0 we can go for a much stronger separation between `row`/`field` on...
@jlittlenz converting to `string_view` is a bit awkward in the general case, for lifetime reasons: it's relatively easy to get yourself into a situation where the underlying string data gets...
Right, @jlittlenz. Generally you should check for nullness before trying to read a value. Although I did just notice that nowadays you are guaranteed to get an empty string when...
For future reference: I just checked and the documentation for `field::as()` does say that it will throw an exception if the field is null. And I think conversion of a...
Thank you for letting me know! Sounds like it would be helpful to have an equivalent to `query` but for prepared statements. And once we had that, the `result` class...
> jtv, > > Hi, i was so my yearly refresh and noticed the comment on the pqxx::result I use it on pqxx::work exec_prepared and pqxx::work exec statements , alot...