From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ivan Trofimov <i(dot)trofimow(at)yandex(dot)ru> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: libpq: PQfnumber overload for not null-terminated strings |
Date: | 2024-02-26 20:14:56 |
Message-ID: | 1965593.1708978496@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ivan Trofimov <i(dot)trofimow(at)yandex(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kirill Reshke | 2024-02-26 20:22:31 | Re: Allow non-superuser to cancel superuser tasks. |
Previous Message | Pavel Stehule | 2024-02-26 20:10:08 | Re: Better error messages for %TYPE and %ROWTYPE in plpgsql |