| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] pgbench - allow to store select results into variables |
| Date: | 2018-11-17 10:43:27 |
| Message-ID: | alpine.DEB.2.21.1811171127180.16105@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I think this patch's Command->lines would benefit from using PQExpBuffer
> (or maybe StringInfo?) for the command string instead of open-coding
> string manipulation and allocation.
Indeed it could be used, but it is not used anywhere in "pgbench": not for
lines, not for variable subtitutions, not for the PREPARE stuff... So I
did not think that it was time to start, I just kept the current style.
Probably it could be a refactoring patch to replace all basic string stuff
with PQExpBuffer infrastructure within pgbench.
> I'm not sure that Command->first_line is really all that useful. It
> seems we go to a lot of trouble to keep it up to date. Isn't it easier
> to chop Command->lines at the first newline when it is needed?
Hmmm, it is needed quite often (about 12 times) to report errors, that
would mean having to handle the truncation in many places, so I felt it
was worth the trouble.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2018-11-17 10:46:59 | RE: pgbench - doCustom cleanup |
| Previous Message | Fabien COELHO | 2018-11-17 10:25:32 | Re: [HACKERS] pgbench - allow to store select results into variables |