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

From Fujii Masao
Subject Re: pgbench - extend initialization phase control
Date
Msg-id CAHGQGwEu0JY2jap4-xBsj=Ynzq3q_7VJX+2au9ojp2r1hQZ6rg@mail.gmail.com
Whole thread Raw
In response to Re: pgbench - extend initialization phase control  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: pgbench - extend initialization phase control  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Thu, Nov 7, 2019 at 5:18 PM Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>
>
> >>> I think that it may break --no-vacuum, and I thought that there may be
> >>> other option which remove things, eventually. Also, having a NO-OP looks
> >>> ok to me.
> >>
> >> As far as I read the code, checkInitSteps() checks the initialization
> >> steps that users specified. The initialization steps string that
> >> "v" was replaced with blank character is not given to checkInitSteps().
> >> So ISTM that dropping the handling of blank character from
> >> checkInitSteps() doesn't break --no-vacuum.
> >>
> > This is a patch which does not allow space character in -I options .
>
> 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? 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()?

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Juan José Santamaría Flecha
Date:
Subject: Re: TAP tests aren't using the magic words for Windows file access
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Add SQL function to show total block numbers in the relation