Re: pgbench - add \aset to store results of a combined query - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pgbench - add \aset to store results of a combined query
Date
Msg-id 20200402080336.GF112468@paquier.xyz
Whole thread Raw
In response to Re: pgbench - add \aset to store results of a combined query  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: pgbench - add \aset to store results of a combined query  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Thu, Apr 02, 2020 at 08:08:08AM +0200, Fabien COELHO wrote:
> ISTM that I submitted a patch to test whether a variable exists in pgbench,
> like available in psql (:{?var} I think), but AFAICS it did not pass. Maybe
> I should resurect it as it would allow to test simply whether an empty
> result was returned to aset, which could make sense in a bench script (get
> something, if it does not exist skip remainder… I can see some interesting
> use cases).

Not sure if improving the readability of the tests is a reason for
this patch.  So I would suggest to just live with relying on debug()
for now to check that a variable with a given prefix exists.

> It does not need to create an UNLOGGED table, a mere "WHERE FALSE" suffices.

Good point, that's cheaper.

> I do not understand why you removed the comment about meta which makes it
> false, so I added something minimal back.

  * type            SQL_COMMAND or META_COMMAND
- * meta            The type of meta-command, or META_NONE if command is SQL
+ * meta            The type of meta-command. On SQL_COMMAND: META_NONE/GSET/ASET.

Oh, OK.  I see your point.  Sorry about that.

>> Perhaps we should also have a test where we return more than 1 row for
>> \get?  The last point is unrelated to this thread though.
>
> Yes, but ISTM that it is not worth a dedicated patch… so I added a test
> similar to the one about empty aset.

Thanks.  So, it looks like everything has been addressed.  Do you have
anything else in mind?

NB: I think that it is really strange to not use an array for the
options in subroutine pgbench() of 001_pgbench_with_server.pl.
Shouldn't this be an array of options instead?  The current logic of
using a splitted string is weak when it comes to option quoting in
perl and command handling in general.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "movead.li@highgo.ca"
Date:
Subject: Re: A bug when use get_bit() function for a long bytea string
Next
From: Kyotaro Horiguchi
Date:
Subject: EINTR while resizing dsm segment.