Re: pg_dump exclusion switches and functions/types
От | Jim C. Nasby |
---|---|
Тема | Re: pg_dump exclusion switches and functions/types |
Дата | |
Msg-id | 20061009193409.GG72517@nasby.net обсуждение исходный текст |
Ответ на | Re: pg_dump exclusion switches and functions/types (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump exclusion switches and functions/types
|
Список | 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)
В списке pgsql-hackers по дате отправления: