Re: pg_dump multi VALUES INSERT

On Tue, Jan 22, 2019 at 3:35 PM David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
wrote:

> On Sat, 19 Jan 2019 at 01:01, Surafel Temesgen <surafel3000(at)gmail(dot)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