Re: pgbench - refactor init functions with buffers

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, David Steele <david(at)pgmasters(dot)net>, 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 18:34:34
Message-ID: 20200328183434.ku6vvcljnrbuqshn@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-03-27 19:57:12 -0400, Tom Lane wrote:
> Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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.

Sure, but that's not at all what was proposed.

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

I don't agree with this. This is a "fresh" usage of StringInfo. That's
different to adding one new printed line among others built with
pqexpbuffer. If we continue adding large numbers of new uses of both
pieces of infrastructure, we're just making things more confusing.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-03-28 18:39:04 Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction
Previous Message Tom Lane 2020-03-28 17:45:00 Re: ssl passphrase callback