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


Reply via email to