Re: pgbench - refactor init functions with buffers

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Steele <david(at)pgmasters(dot)net>, 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 09:46:02
Message-ID: alpine.DEB.2.21.2003281029430.16227@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Tom,

>> I cannot say that I "want" to fix something which already works the same
>> way, because it is against my coding principles. [...]
>> I counted nearly 3500 calls under src/bin.
>
> Yeah, that's the problem. If someone does come forward with a patch to do
> that, I think it'd be summarily rejected, at least in high-traffic code
> like pg_dump. The pain it'd cause for back-patching would outweigh the
> value.

What about "typedef StringInfoData PQExpBufferData" and replacing
PQExpBuffer by StringInfo internally, just keeping the old interface
around because it is there? That would remove a few hundreds clocs.

ISTM that with inline and varargs macro the substition can be managed
reasonably lightly, depending on what level of compatibility is required
for libpq: should it be linkability, or requiring a recompilation is ok?

A clear benefit is that there are quite a few utils for PQExpBuffer in
"fe_utils/string_utils.c" which would become available for StringInfo,
which would help using StringInfo without duplicating them.

> That being the case, I'd think a better design principle is "make your
> new code look like the code around it",

Yep.

> 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.

Well, that is what I was saying, but at 2 against 1, I fold.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-03-28 09:59:34 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message Fabien COELHO 2020-03-28 09:27:41 Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)