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.