Hello Tom,
>> I cannot say that I "want" to fix something which already works the same
>> way, because it is against my coding principles. [...]
>> I counted nearly 3500 calls under src/bin.
>
> Yeah, that's the problem. If someone does come forward with a patch to do
> that, I think it'd be summarily rejected, at least in high-traffic code
> like pg_dump. The pain it'd cause for back-patching would outweigh the
> value.
What about "typedef StringInfoData PQExpBufferData" and replacing
PQExpBuffer by StringInfo internally, just keeping the old interface
around because it is there? That would remove a few hundreds clocs.
ISTM that with inline and varargs macro the substition can be managed
reasonably lightly, depending on what level of compatibility is required
for libpq: should it be linkability, or requiring a recompilation is ok?
A clear benefit is that there are quite a few utils for PQExpBuffer in
"fe_utils/string_utils.c" which would become available for StringInfo,
which would help using StringInfo without duplicating them.
> That being the case, I'd think a better design principle is "make your
> new code look like the code around it",
Yep.
> which would tend to weigh against introducing StringInfo uses into
> pgbench when there's none there now and a bunch of PQExpBuffer instead.
> So I can't help thinking the advice you're being given here is suspect.
Well, that is what I was saying, but at 2 against 1, I fold.
--
Fabien.
