Jeroen Vermeulen

Thanks!

One annoying problem is that the string conversion API does not have a way to pass the prevailing client encoding. For all the other data types, the encoding is irrelevant...

For #841 I intend to make encodings a "thing" in the libpqxx API. That may provide one small step for this. There's another issue though that we haven't touched upon:...

I don't know why I never mentioned this in here before... We _do_ now have support for reading arrays, but as a separate `field` member function: `as_sql_array()`. This parses an...

I thought I did the work for this, sometime long ago. @alexolog do you know exactly which concepts are missing, and how I implement them?

I think we should be able to get some of the information by trying to instantiate a template that expects a `std::random_access_iterator`, but passing it a `pqxx::const_row_iterator` or a `pqxx::const_result_iterator`....

Implementing `operator[]` isn't so easy. The result iterator already _has_ an operator, but it does something different.

@alexolog for some reason I think some conversation disappeared. But you're right — I wasn't aware of the `operator[]` requirement back when I wrote that code. So the result iterator...

We should be able to resolve this together with #770. Rewrite the iterator types so that they're no longer closely intertwined with the row/field types; give `row` and `const_result_iterator` different...

Tempting: it now looks like a "divorce" between `result::const_iterator::operator[]` and `row::operator[]` probably wouldn't break a lot of code! I tried commenting out the `operator[]` on the iterator, and the only...