Re: libpq: PQfnumber overload for not null-terminated strings - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: libpq: PQfnumber overload for not null-terminated strings
Date
Msg-id CAGECzQSMPhPm8B+CGeP5bSwpTrCAQzvHd9x-PqZ9TWU8DQsjcA@mail.gmail.com
Whole thread Raw
In response to Re: libpq: PQfnumber overload for not null-terminated strings  (Ivan Trofimov <i.trofimow@yandex.ru>)
List pgsql-hackers
On Tue, 27 Feb 2024 at 15:49, Ivan Trofimov <i.trofimow@yandex.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.



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
Next
From: Kirill Reshke
Date:
Subject: Re: Allow non-superuser to cancel superuser tasks.