| From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
|---|---|
| To: | Ivan Trofimov <i(dot)trofimow(at)yandex(dot)ru> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: libpq: PQfnumber overload for not null-terminated strings |
| Date: | 2024-02-27 18:57:39 |
| Message-ID: | CAGECzQSMPhPm8B+CGeP5bSwpTrCAQzvHd9x-PqZ9TWU8DQsjcA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 27 Feb 2024 at 15:49, Ivan Trofimov <i(dot)trofimow(at)yandex(dot)ru> wrote:
> Caching the result of PQfnumber could be done, but would result in
> somewhat of a mess on a call-site.
To be clear I meant your wrapper around libpq could internally cache
this, then the call sites of users of your wrapper would not need to
be changed. i.e. your Result could contain a cache of
columnname->columnumber mapping that you know because of previous
calls to PQfnumber on the same Result.
> I like your idea of 'PQfnumberRaw': initially i was only concerned about
> a null-terminated string requirement affecting my interfaces (because
> users complained about that to me,
> https://github.com/userver-framework/userver/issues/494) but I think
> PQfnumberRaw could solve both problems (PQfnumber being a bottleneck
> when called repeatedly and a null-terminated string requirement)
> simultaneously.
Feel free to send a patch for this.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kirill Reshke | 2024-02-27 18:59:00 | Re: Allow non-superuser to cancel superuser tasks. |
| Previous Message | Alvaro Herrera | 2024-02-27 18:11:07 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |