Re: pgbench - extend initialization phase control

Hello,

> Failed regression test. It's necessary to change the first a in “allowed
> step characters are” to uppercase A in the regression test of
> 002_pgbench_no_server.pl.

Argh. I think I ran the test, then stupidly updated the message afterwards
to better match best practices, without rechecking:-(

> The behavior of "g" is different between v12 and the patche, and
> backward compatibility is lost. In v12, BEGIN and COMMIT are specified
> only by choosing "g". It's a problem that backward compatibility is
> lost.

Somehow yes, but I do not see this as an actual problem from a functional
point of view: it just means that if you use a 'dtgvp' with the newer
version and if the inserts were to fail, then they are not under an
explicit transaction, so previous inserts are not cleaned up. However,
this is a pretty unlikely case, and anyway the error is reported, so any
user would be expected not to go on after the initialization phase.

So basically I do not see the very small regression for an unlikely corner
case to induce any problem in practice.

The benefit of controlling where begin/end actually occur is that it may
have an impact on performance, and it allows to check that.

> When using ( and ) with the -I, the documentation should indicate that double
> quotes are required,

Or single quotes, or backslash, if launch from the command line. I added a
mention of escaping or protection in the doc in that case.

> and "v" not be able to enclose in ( and ).

That is a postgresql limitation, which may evolve. There could be others.
I updated the doc to say that some commands may not work inside an
explicit transaction.

> When g is specified, null is inserted in the filler column of
> pgbentch_tellrs, acounts, branches. But when G is specified, empty
> string is inserted.

Indeed there is a small diff. ISTM that the actual filling with the
initial client version is NULL for branches and tellers, and a
blank-padded string for accounts.

I fixed the patch so that the end-result is the same with both g and G.

> Do you have any intention of this difference?

Yes and no.

I intended that tellers & branches filler are filled, but I did not really
notice that the client side was implicitely using NULL, although it says
so in a comment. Although I'm not happy with the fact because it cheats
with the benchmark design which requires the filler columns to be really
filled and stored as is, it is indeed the place to change this (bad)
behavior.

Attached a v4 with the updates described above.

--
Fabien.