> However, I do think you could convert this per-row overhead in your
> case to per-query overhead by caching the result of PQfnumber for each
> unique C++ string_view. Afaict that should solve your performance
> problem.
Absolutely, you're right.
The problem here is not that it's impossible to write it in a performant
way, but rather that it's impossible to do so in a performant _and_
clean way given the convenient abstractions wrapper-libraries provide:
here's a `Result`, which consists of `Row`s, which in turn consist of
`Field`s.
The most natural and straightforward way to iterate over a `Result`
would be in the lines of that loop, and people do write code like that
because it's what they expect to just work given the abstractions (and
it does, it's just slow).
Caching the result of PQfnumber could be done, but would result in
somewhat of a mess on a call-site.
I like your idea of 'PQfnumberRaw': initially i was only concerned about
a null-terminated string requirement affecting my interfaces (because
users complained about that to me,
https://github.com/userver-framework/userver/issues/494), but I think
PQfnumberRaw could solve both problems (PQfnumber being a bottleneck
when called repeatedly and a null-terminated string requirement)
simultaneously.