Re: pgbench - refactor init functions with buffers

From: David Steele <david(at)pgmasters(dot)net>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Andres Freund <andres(at)anarazel(dot)de>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbench - refactor init functions with buffers
Date: 2020-03-28 14:36:58
Views: Raw Message | Whole Thread | Download mbox | Resend email
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?


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rijkers 2020-03-28 14:39:02 Re: proposal \gcsv
Previous Message James Coleman 2020-03-28 14:31:51 Re: improve transparency of bitmap-only heap scans