Thanks for the quick reply.
> If you need counted strings
> for PQfnumber, wouldn't you need them for every single other
> string-based API in libpq as well?
No, not really.
Thing is, out of all the functions listed in "34.3.2. Retrieving Query
Result Information" and "34.3.3. Retrieving Other Result Information"
PQfnumber is the only (well, technically also PQprint) one that takes a
string as an input.
As far as I know PQfnumber is the only portable way to implement "give
me the the value at this row with this 'column_name'", which is an
essential feature for any kind of client-side parsing.
Right now as a library writer in a higher-level language I'm forced to
either
* Sacrifice performance to ensure 'column_name' is null-terminated
(that's what some bindings in Rust do)
* Sacrifice interface quality by requiring a null-terminated string,
which is not necessary idiomatic (that's what we do)
* Sacrifice usability by requiring a user to guarantee that the
'string_view' provided is null-terminated (that's what libpqxx does, for
example)
I don't think it's _that_ big of a deal, but could it be QoL improvement
nice enough to be worth of a tiny addition into libpq interface?