| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Surafel Temesgen <surafel3000(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dump multi VALUES INSERT |
| Date: | 2019-01-23 09:08:34 |
| Message-ID: | alpine.DEB.2.21.1901230959220.16643@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello David & Surafel,
About this v10:
Patch applies and compiles cleanly, local & global "make check" ok.
A few comments, possibly redundant with some already in the thread.
Out of abc-order rows-per-inserts option in getopt struct.
help string does not specify the expected argument.
I still think that the added rows_per_insert field is useless, ISTM That
"int dump_inserts" can be reused, and you could also drop boolean
got_rows_per_insert.
The feature is not tested anywhere. I still think that there should be a
test on empty/small/larger-than-rows-per-insert tables, possibly added to
existing TAP-tests.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2019-01-23 09:34:06 | inherited primary key misbehavior |
| Previous Message | Oleksandr Shulgin | 2019-01-23 09:07:27 | Re: Analyze all plans |