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.
