Re: pgbench - extend initialization phase control - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench - extend initialization phase control
Date
Msg-id alpine.DEB.2.21.1911071012320.20647@lancre
Whole thread Raw
In response to Re: pgbench - extend initialization phase control  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: pgbench - extend initialization phase control
List pgsql-hackers
Hello Masao-san,

>> I do not think that this is desirable. It would be a regression, and
>> allowing a no-op is not an issue in anyway.
>
> Why is that regression, you think?

Because "pgbench -I ' d'" currently works and it would cease to work after 
the patch.

> I think that's an oversight. If I'm missing something and accepting a 
> blank character as no-op in also checkInitSteps() is really necessary 
> for some reasons, which should be documented. But, if so, another 
> question is; why should only blank character be treated as no-op, in 
> checkInitSteps()?

The idea is to have one character that can be substituted to remove any 
operation.

On principle, allowing a no-op character, whatever the choice, is a good 
idea, because it means that the caller can take advantage of that if need 
be.

I think that the actual oversight is that the checkInitSteps should be 
called at the beginning of processing initialization steps rather than 
while processing -I, because currently other places modify the 
initialization string (no-vacuum, foreign key) and thus are not checked.

I agree that it should be documented.

Attached patch adds a doc and moves the check where it should be, and 
modifies a test with an explicit no-op space initialization step.

-- 
Fabien.
Attachment

pgsql-hackers by date:

Previous
From: "曾文旌(义从)"
Date:
Subject: Re: [Proposal] Global temporary tables
Next
From: Pavel Stehule
Date:
Subject: Re: [Proposal] Global temporary tables