On Sat, 19 Jan 2019 at 01:01, Surafel Temesgen <surafel3000@gmail.com> wrote: > if you specified --inserts option you already specified the number of rows per statement which is 1 . > if more than one rows per statement needed it must be specified using --rows-per-insert > and specifying one row per statement using --inserts option at the same time specify > different number of rows per statement with --rows-per-insert option seems conflicting to me.
So you're saying an INSERT, where you insert multiple rows in a single statement is not an insert? That logic surprises me. --inserts makes pg_dump use INSERTs rather than COPY. --rows-per-inserts still uses INSERTs. I'd love to know why you think there's some conflict with that.
By your logic, you could say --column-inserts and --inserts should also conflict, but they don't. --column-inserts happens to be coded to imply --inserts. I really suggest we follow the lead from that. Doing it this way reduces the complexity of the code where we build the INSERT statement. Remember that a patch that is overly complex has much less chance of making it. I'd really suggest you keep this as simple as possible.
okay i understand it now .Fabien also comment about it uptread i misunderstand it as
using separate new option.
It also seems perfectly logical to me to default --rows-per-insert to 1 so that when --inserts is specified we do 1 row per INSERT. If the user changes that value to something higher then nothing special needs to happen as the function building the INSERT statement will always be paying attention to whatever the --rows-per-insert value is set to. That simplifies the logic meaning you don't need to check if --inserts was specified.
okay .thank you for explaining. i attach a patch corrected as such