Hello Andres,
That being the case, I'd think a better design principle is "make your
new code look like the code around it", 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.
I don't agree with this. This is a "fresh" usage of StringInfo. That's
different to adding one new printed line among others built with
pqexpbuffer. If we continue adding large numbers of new uses of both
pieces of infrastructure, we're just making things more confusing.
My 0.02 € :
- I'm in favor or having one tool for one purpose, so a fe/be common
StringInfo interface is fine with me;
- I prefer to avoid using both PQExpBuffer & StringInfo in the same file,
because they do the exact same thing and it is locally confusing;
- I'd be fine with switching all of pgbench to StringInfo, as there are
only 31 uses;
- But, pgbench relies on psql scanner, which uses PQExpBuffer in
PsqlScanState, so mixing is unavoidable, unless PQExpBuffer & StringInfo
are the same thing (i.e. typedef + cpp/inline/function wrappers);
- There are 1260 uses of PQExpBuffer in psql that, although they are
trivial, I'm in no hurry to update.
--
Fabien.
