Jeroen Vermeulen

Thanks for working on this. Be aware that the binary format is neither documented nor guaranteed to be stable, which is one of the reasons I've never built in generic...

@bj8sk are you still interested in working on this? If not, we can close the PR.

Thanks @bj8sk . It's pretty complicated when we consider everything... Mainly I think we need a way to guard against getting a type wrong, or a changing format. The text...

The reason is that so far, encodings and encoding groups are entirely hidden from the application. If we're going to introduce it into the API, then we'll have to answer...

Yes, I suppose using the encoding's _name_ would solve it. I'd probably want a way for the caller to move that string lookup out of loops though. We'd also need...

@fallenworld1 the problem with specialising `field::as()` is that it's not the only place where we use string conversion. We'd probably have to do that for more functions. But much worse,...

@alexolog two points that I want to get out of the way: 1. Server encoding is (thankfully) irrelevant here. It's client encoding that matters. (Unfortunately it can change on the...

Phew. I _finally_ got the documentation working again. That's been a big de-motivating factor for the last three months. @alexolog @fallenworld1 I'd like to focus on this issue next, barring...

Again there were lots of things to distract me but I did discover that `pqxx::result` is _already_ aware of its encoding. So I'm now thinking along the lines of @fallenworld1's...

I'm trying the first step. (At the _second_ step I run into the problem that I need a partial template specialisation for `pqxx::field::as()`. Current C++ does not allow partial specialisations...