Re: pgbench - refactor init functions with buffers

David Steele <david@pgmasters.net>

From: David Steele <david@pgmasters.net>
To: Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>, Andres Freund <andres@anarazel.de>, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>, Dilip Kumar <dilipbalaut@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-03-28T14:36:58Z
Lists: pgsql-hackers
On 3/27/20 9:52 PM, Alvaro Herrera wrote:
> On 2020-Mar-27, Tom Lane wrote:
> 
>> 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.
> 
> +1 for keeping it PQExpBuffer-only, until such a time when you need a
> StringInfo feature that's not in PQExpBuffer -- and even at that point,
> I think you'd switch just that one thing to StringInfo, not the whole
> program.

I think I need to be careful what I joke about.  It wasn't my intention 
to advocate changing all the existing *PQExpBuffer() calls in bin.

But, the only prior committer to look at this patch expressed a 
preference for StringInfo so in the absence of any other input I thought 
it might move the patch forward if I reinforced that.  Now it seems the 
consensus has moved in favor of *PQExpBuffer().

Fabien has provided a patch in each flavor, so I guess the question is: 
is it committable either way?

Regards,
-- 
-David
david@pgmasters.net



Commits

  1. pgbench: Use PQExpBuffer to simplify code that constructs SQL.

  2. Make command order in test more sensible