Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization
Date
Msg-id alpine.DEB.2.20.1708221009100.19265@lancre
Whole thread Raw
In response to Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Masahiko Sawada <sawada.mshk@gmail.com>)
List 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 by date:

Previous
From: Pavel Stehule
Date:
Subject: [HACKERS] proposal: psql command \graw
Next
From: Aleksander Alekseev
Date:
Subject: Re: [HACKERS] proposal: psql command \graw