|From:||David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>|
|To:||Surafel Temesgen <surafel3000(at)gmail(dot)com>|
|Cc:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, 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|
|Views:||Raw Message | Whole Thread | Download mbox|
On Wed, 23 Jan 2019 at 02:13, Surafel Temesgen <surafel3000(at)gmail(dot)com> wrote:
> okay .thank you for explaining. i attach a patch corrected as such
I did a bit of work to this to fix a bunch of things:
1. Docs for --rows-per-insert didn't mention anything about a parameter.
2. You'd not followed the alphabetical order of how the parameters are
3. Various parts of the docs claimed that --inserts just inserted 1
row per statement. Those needed to be updated.
4. New options out of order in --help. The rest were in alphabetical order.
5. DumpOptions struct variable was not in the right place. It was
grouped in with some parameterless options.
6. Code in dumpTableData_insert() was convoluted. Not sure what you
had added end_of_statement for or why you were checking PQntuples(res)
== 0. You'd also made the number_of_row variable 1-based and set it
to 1 when we had added 0 rows. You then checked for the existence of 1
row by checking the variable was > 1... That made very little sense to
me. I've pretty much put back the code that I had sent to you
previously, just without the part where I split the row building code
out into another function.
7. A comment in dumpTableData_insert() claimed that the insertStmt
would end in "VALUES(", but it'll end in "VALUES ". I had updated that
in my last version, but you must have missed that.
8. I've made it so --rows-per-insert implies --inserts. This is
aligned with how --column-inserts behaves.
I changed a few other things. I simplified the condition that raises
an error when someone does --on-conflict-do-nothing without the
--inserts option. There was no need to check for the other options
that imply --inserts since that will already be enabled if one of the
other options has.
I also removed most of the error checking you'd added to ensure that
the --rows-per-insert parameter was a number. I'd have kept this but
I saw that we do nothing that special for the compression option. I
didn't see why --rows-per-insert was any more special. It was quite a
bit of code for very little reward.
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
|Next Message||Kyotaro HORIGUCHI||2019-01-23 08:35:02||Re: Protect syscache from bloating with negative cache entries|
|Previous Message||leif||2019-01-23 06:57:27||Fwd: Re: BUG #15589: Due to missing wal, restore ends prematurely and opens database for read/write|