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

From David Steele
Subject Re: pgbench - refactor init functions with buffers
Date
Msg-id 053de93b-4208-c853-55c8-fb0d52da562b@pgmasters.net
Whole thread Raw
In response to Re: pgbench - refactor init functions with buffers  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pgbench - refactor init functions with buffers  (Fabien COELHO <coelho@cri.ensmp.fr>)
List 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



pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: improve transparency of bitmap-only heap scans
Next
From: Erik Rijkers
Date:
Subject: Re: proposal \gcsv