|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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?
|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|