On Fri, 18 Jan 2019 at 01:15, Surafel Temesgen <surafel3000@gmail.com> wrote: > The attache patch use your method mostly
I disagree with the "mostly" part. As far as I can see, you took the idea and then made a series of changes to completely break it. For bonus points, you put back my comment change to make it incorrect again.
Here's what I got after applying your latest patch:
[...] INSERT INTO public.t VALUES (1); ) INSERT INTO public.t VALUES (, ( 2); ) INSERT INTO public.t VALUES (, ( 3); ) INSERT INTO public.t VALUES (, ( 4); ); INSERT INTO public.t VALUES (5); ) INSERT INTO public.t VALUES (, ( 6); ) INSERT INTO public.t VALUES (, ( 7); ) INSERT INTO public.t VALUES (, ( 8); ); INSERT INTO public.t VALUES (9); ) ;
I didn't test, but I'm pretty sure that's not valid INSERT syntax.
this happen because i don't disallow the usage of --inserts and --rows-per-insert
option together.it should be error out in those case.i correct it in attached patch
I'd suggest taking my changes and doing the plumbing work to tie the rows_per_statement into the command line arg instead of how I left it hardcoded as 3.
>> + When using <option>--inserts</option>, this allows the maximum number >> + of rows per <command>INSERT</command> statement to be specified. >> + This setting defaults to 1. >> > i change it too except "This setting defaults to 1" because it doesn't have default value. > 1 row per statement means --inserts option .
If it does not default to 1 then what happens when the option is not specified
if --inserts option specified it use single values insert statement otherwise