Re: Patch: Add --no-comments to skip COMMENTs with pg_dump
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Michael Paquier <michael.paquier@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Fabrízio Mello <fabriziomello@gmail.com>, Robins Tharakan <tharakan@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, David Fetter <david@fetter.org>, Tom Lane <tgl@sss.pgh.pa.us>, "David G. Johnston" <david.g.johnston@gmail.com>
Date: 2017-09-11T14:43:55Z
Lists: pgsql-hackers
On Sun, Sep 10, 2017 at 6:25 PM, Stephen Frost <sfrost@snowman.net> wrote: > * Michael Paquier (michael.paquier@gmail.com) wrote: >> As there begins to be many switches of this kind and much code >> duplication, I think that some refactoring into a more generic switch >> infrastructure would be nicer. > > I have been thinking about this also and agree that it would be nicer, > but then these options would just become "shorthand" for the generic > switch. I don't really like the "generic switch infrastructure" concept. I think it will make specifying behaviors harder without any corresponding benefit. There are quite a few --no-xxx switches now but the total number of them that we could conceivably end up with doesn't seem to be a lot bigger than what we have already. Now, if we want switches to exclude a certain kind of object (e.g. table, function, text search configuration) from the backup altogether, that should be done in some generic way, like --exclude-object-type=table. But that's not what this is about. This is about excluding a certain kind of property (comments, in this case) from being backed up. And an individual kind of object doesn't have many more properties than what we already handle. So I think this is just an excuse for turning --no-security-labels into --no-object-property=security-label. To me, that's just plain worse. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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