Ivan Trofimov <i.trofi...@yandex.ru> writes: >> 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. I think that's a mighty myopic definition of which APIs would need counted-string support if we were to make that a thing in libpq. Just for starters, why are you only concerned with processing a query result, and not with the functions needed to send the query? > 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) I'd go with that. You would have a very hard time convincing me that the per-query overhead that building a null-terminated string adds is even measurable compared to the time needed to send, process, and receive the query. regards, tom lane