Re: pgbench - extend initialization phase control
От | Fabien COELHO |
---|---|
Тема | Re: pgbench - extend initialization phase control |
Дата | |
Msg-id | alpine.DEB.2.21.1911071012320.20647@lancre обсуждение исходный текст |
Ответ на | Re: pgbench - extend initialization phase control (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: pgbench - extend initialization phase control
|
Список | 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.
Вложения
В списке pgsql-hackers по дате отправления: