Re: pg_dump exclusion switches and functions/types
Jim Nasby <jim@nasby.net>
From: "Jim C. Nasby" <jim@nasby.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Fetter <david@fetter.org>, Gregory Stark <stark@enterprisedb.com>, Kris Jurka <books@ejurka.com>, pgsql-hackers@postgresql.org
Date: 2006-10-09T19:34:09Z
Lists: pgsql-hackers
On Mon, Oct 09, 2006 at 01:59:18PM -0400, Tom Lane wrote: > "Jim C. Nasby" <jim@nasby.net> writes: > > On Sat, Oct 07, 2006 at 06:22:19PM -0700, David Fetter wrote: > >> On Fri, Oct 06, 2006 at 10:28:21PM -0400, Gregory Stark wrote: > >>> My first thought is that the rule should be to apply all the > >>> inclusion switches (implicitly including everything if there are > >>> none), then apply all the exclusion switches. > >> > >> +1 :) > >> Order-dependent switches are a giant foot gun. > > > They're also very powerful, as anyone who's ever used them in a > > non-trivial rsync (or rdiff-backup) scenareo can tell you. > > Sure, but the question is whether that incremental gain in capability > is worth the extra logical complexity. I'm inclined to think that many > more users would get burned by the complexity than would have use for it. > Considering that we've gotten along this long with only the most > primitive selection capabilities in pg_dump, it doesn't seem like > there's an enormous demand for highly refined capabilities. > > (And I agree with David's comment that it might be better to reserve > such behavior for a configuration file than to put it on the command > line.) I can certainly see the logic in putting the more advanced capability in a config file of some kind (though, I think a simple include/exclude file is best for this...) The question becomes: do we want incompatible behavior between the config file and the command line? And which over-rides what? -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)