Re: pg_dump exclusion switches and functions/types - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump exclusion switches and functions/types
Date
Msg-id 4335.1160416758@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump exclusion switches and functions/types  ("Jim C. Nasby" <jim@nasby.net>)
Responses Re: pg_dump exclusion switches and functions/types  ("Jim C. Nasby" <jim@nasby.net>)
Re: pg_dump exclusion switches and functions/types  ("Greg Sabino Mullane" <greg@turnstep.com>)
List pgsql-hackers
"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.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: width_bucket function for timestamps
Next
From: Chris Browne
Date:
Subject: Re: OT: Is there a LinkedIn group for Postgresql?