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

From Tom Lane
Subject Re: pgbench - refactor init functions with buffers
Date
Msg-id 31903.1585353432@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgbench - refactor init functions with buffers  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: pgbench - refactor init functions with buffers  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: pgbench - refactor init functions with buffers  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: pgbench - refactor init functions with buffers  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
>>> Ok. I find it strange to mix PQExpBuffer & StringInfo in the same file.

>> Agreed, but we'd rather use StringInfo going forward.  However, I don't think
>> that puts you on the hook for updating all the PQExpBuffer references.
>> Unless you want to...

> I cannot say that I "want" to fix something which already works the same
> way, because it is against my coding principles.
> However there may be some fun in writing a little script to replace one
> with the other automatically. 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.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Possible copy and past error? (\usr\backend\commands\analyze.c)
Next
From: Justin Pryzby
Date:
Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace onthe fly