Andres Freund <andres@anarazel.de> writes:
> On 2020-03-28 14:49:31 -0400, Tom Lane wrote:
>> Why? I'm not aware of any intention to deprecate/remove PQExpBuffer,
>> and I doubt it'd be a good thing to try. It does some things that
>> StringInfo won't, notably cope with OOM without crashing.
> - code using it cannot easily be shared between frontend/backend (no
> memory context integration etc)
True, but also pretty irrelevant for pgbench and similar code.
> - most code does *not* want to deal with the potential for OOM without
> erroring out
Fair point.
> - it's naming is even more confusing than StringInfo
Eye of the beholder ...
> - it introduces dependencies to libpq even when not needed
Most of our FE programs do include libpq, and pgbench certainly does,
so this seems like a pretty irrelevant objection as well.
> - both stringinfo and pqexpbuffer are performance relevant in some uses,
> needing to optimize both is wasted effort
I'm not aware that anybody is trying to micro-optimize either. Even
if someone is, it doesn't imply that they need to change both.
> - we shouldn't expose everyone to both APIs except where needed - it's
> stuff one has to learn
That situation is unlikely to change in the foreseeable future.
Moreover, using both APIs in one program, where we were not before,
makes it worse not better.
regards, tom lane
