Re: pg_dump multi VALUES INSERT
От | David Rowley |
---|---|
Тема | Re: pg_dump multi VALUES INSERT |
Дата | |
Msg-id | CAKJS1f_tU-eHX0zRnBzn-g9gtdToBPkP+nBtkd_7oxZgBK86-Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump multi VALUES INSERT (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: pg_dump multi VALUES INSERT
|
Список | pgsql-hackers |
On Fri, 22 Feb 2019 at 14:40, David Rowley <david.rowley@2ndquadrant.com> wrote: > > On Tue, 19 Feb 2019 at 02:34, Surafel Temesgen <surafel3000@gmail.com> wrote: > > I see that there are already a test for zero column table in test_fourth_table_zero_col > > and if am not wrong table_index_stats is empty table > > Maybe Fabien would like to see a test that dumps that table with > --rows-per-insert=<something above one> to ensure the output remains > as the other test. I think it might be a good idea too. This patch was failing to build due to the new extra_float_digits option that's been added to pg_dump. It was adding an additional case for 8 in the getopt_long switch statement. In the attached, I've changed it to use value 9 and 10 for the new options. I also went ahead and added the zero column test that Fabien mentioned. Also added the missing backslash from the other test that had been added. Fabien also complained about some wording in the docs. I ended up changing this a little bit as I thought the change was a little uninformative about what rows won't be restored when an INSERT fails. I've changed this so that it mentions that all rows which are part of the same INSERT command will fail in the restore. I think this can be marked as ready for committer now, but I'll defer to Fabien to see if he's any other comments. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: