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