Re: pgbench - refactor init functions with buffers

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: 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: 2019-11-06 05:48:14
Message-ID: alpine.DEB.2.21.1911060631510.27573@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Andres,

>> Attached v3 shorten some lines and adds "append_tablespace".

A v4 which just extends the patch to newly added 'G'.

> I'd prefer not to expand the use of pqexpbuffer in more places, and
> instead rather see this use StringInfo, now that's also available to
> frontend programs.

Franckly, one or the other does not matter much to me.

However, pgbench already uses PQExpBuffer, it uses PsqlScanState which
also uses PQExpBuffer, and it intrinsically depends on libpq which
provides PQExpBuffer: ISTM that it makes sense to keep going there, unless
PQExpBuffer support is to be dropped.

Switching all usages would involve a significant effort and having both
PQExpBuffer and string_info used in the same file for the same purpose
would be confusing.

--
Fabien.

Attachment Content-Type Size
pgbench-buffer-4.patch text/x-diff 13.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuro Yamada 2019-11-06 05:49:49 Re: progress report for ANALYZE
Previous Message Yuya Watari 2019-11-06 04:56:46 Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )