On Mon, Oct 09, 2006 at 02:34:09PM -0500, Jim C. Nasby wrote:
> 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?
The way I've cut this Gordian knot in the past is simply to make
command-line and file-based options for a given thing (e.g.
exclusion/inclusion) mutually exclusive and throw an error if somebody
attempts to mix them.
Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter
Remember to vote!
