On Tue, 27 Feb 2024 at 15:49, Ivan Trofimov <i.trofi...@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.