Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization |
Дата | |
Msg-id | alpine.DEB.2.20.1708221009100.19265@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
|
Список | pgsql-hackers |
>> Why not allow -I as a short option for --custom-initialize? > > Other options for similar purpose such as --foreign-keys also have > only a long option. Since I think --custom-initialize option is in the > same context as other options I didn't add short option to it for now. > Because the options name is found by a prefix searching we can use a > short name --cu for now. Hmmm. I like short options:-) > I'm inclined to remove the restriction so that we can specify > --foreign-keys, --no-vacuum and --custom-initialize at the same time. Ok. I favor that as well. > I think a list of char would be better here rather than a single > malloced string to remove particular initialization step easily. > Thought? My thought is not to bother with a list of char. To remove a char from a string, I suggest to allow ' ' to stand for nothing and be skipped, so that substituting a letter by space would simply remove an initialization phase. For adding, realloc & append. -- Fabien.
В списке pgsql-hackers по дате отправления: