Re: pgbench - refactor init functions with buffers
David Steele <david@pgmasters.net>
From: David Steele <david@pgmasters.net>
To: Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>, Andres Freund <andres@anarazel.de>,
Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>,
Dilip Kumar <dilipbalaut@gmail.com>,
PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-03-28T14:36:58Z
Lists: pgsql-hackers
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 > program. 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? Regards, -- -David david@pgmasters.net
Commits
-
pgbench: Use PQExpBuffer to simplify code that constructs SQL.
- 9796f455c38e 14.0 landed
-
Make command order in test more sensible
- ad4b7aeb8443 13.0 cited