Ivan Trofimov <i.trofimow@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
