On Fri, 18 Jan 2019 at 01:15, Surafel Temesgen <surafel3...@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: $ pg_dump --table=t --inserts --rows-per-insert=4 postgres [...] 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. 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? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
