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 i
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 Res
Hi!
This one comes from C++'s `std::string_view`: being just a `const char*`
plus the `size`, it's a very convenient type to use in interfaces which
don't need an ownership of the data passed in.
Unfortunately, `PQfnumber` expects a null-terminated string, which
`std::string_view` can not gu
Hi Tom! Thank you for considering this.
It adds a whole new set of programmer-error possibilities, and I doubt
it saves enough in typical cases to justify creating such a foot-gun.
Although I agree it adds a considerable amount of complexity, I'd argue
it doesn't bring the complexity to a new l
In a presumably very common case of repeatedly executing the same statement,
this leads to
both client and server parsing/sending exactly the same RowDescritpion data
over and over again.
Instead, library user could acquire a statement result RowDescription once (via
PQdescribePrepared),
and re
Hi!
Currently libpq sends B(ind), D(escribe), E(execute), S(ync) when
executing a prepared statement.
The response for that D message is a RowDescription, which doesn't
change during prepared
statement lifetime (with the attributes format being an exception, as
they aren't know before exe
