Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Stephen Frost <sfrost@snowman.net>, Robins Tharakan <tharakan@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Fabrízio Mello <fabriziomello@gmail.com>, David Fetter <david@fetter.org>, Robert Haas <robertmhaas@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Michael Paquier <michael.paquier@gmail.com>
Date: 2018-01-25T22:28:57Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Well, the current implementation compares a dozen of pg_dump output text > files, three hundred lines apiece, against a thousand of regexes (give > or take). Whenever there is a mismatch, what you get is "this regexp > failed to match <three hundred lines>" (or sometimes "matched when it > should have not"), so looking for the mismatch is quite annoying. Yeah, I've been getting my nose rubbed in that over the past couple days of pg_dump hacking: when you get a failure, the output is really unfriendly, even by the seriously low standards of the rest of our TAP tests. I'm not sure if Alvaro's idea is the best way to improve that, but it's something to think about. The thing that was annoying me though is that it seems like every test case interacts with every other test case, or at least way more of them than one could wish, due to the construction of that big hash constant. That's what I find unmaintainable. regards, tom lane
Commits
-
Support --no-comments in pg_dump, pg_dumpall, pg_restore.
- 1368e92e16a0 11.0 landed
-
Improve pg_dump's handling of "special" built-in objects.
- 5955d934194c 11.0 landed