Re: pgbench - refactor init functions with buffers - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench - refactor init functions with buffers
Date
Msg-id alpine.DEB.2.21.2003290727580.16227@pseudo
Whole thread Raw
In response to Re: pgbench - refactor init functions with buffers  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: WAL usage calculation patch
Next
From: Amit Kapila
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions