Re: pg_dumpall --exclude-database option
От | Fabien COELHO |
---|---|
Тема | Re: pg_dumpall --exclude-database option |
Дата | |
Msg-id | alpine.DEB.2.21.1812250916210.32444@lancre обсуждение исходный текст |
Ответ на | Re: pg_dumpall --exclude-database option (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Ответы |
Re: pg_dumpall --exclude-database option
Re: pg_dumpall --exclude-database option |
Список | pgsql-hackers |
Hello Andrew, > Rebased and updated patch attached. Here is a review of v5, sorry for the delay. Patch applies cleanly, compiles, "make check" is ok. I do not see Michaël's issue, and do not see how it could be so, for me the whole database-specific section generated by the underlying "pg_dump" call is removed, as expected. All is well for me, I turned the patch as ready. While poking around the dump output, I noticed some unrelated points: * Command "pg_dump" could tell which database is dumped in the output at the start of the section, eg: -- -- PostgreSQL database "foo" dump -- Or "pg_dumpall" could issue a comment line in the output telling which database is being considered. * The database dumps should have an introductory comment, like there is one for roles, eg: -- -- Databases -- * On extensions, the dump creates both the extension and the extension comment. However, ISTM that the extension comment is already created by the extension, so this is redundant: -- -- Name: pg_dirtyread; Type: EXTENSION; Schema: -; Owner: -- CREATE EXTENSION IF NOT EXISTS pg_dirtyread WITH SCHEMA public; -- -- Name: EXTENSION pg_dirtyread; Type: COMMENT; Schema: -; Owner: -- COMMENT ON EXTENSION pg_dirtyread IS 'Read dead but unvacuumed rows from table'; Maybe it should notice that the comment belongs to the extension and need not be updated? -- Fabien.
В списке pgsql-hackers по дате отправления: