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.
