Re: pg_dump exclusion switches and functions/types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
Cc: David Fetter <david(at)fetter(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>, Kris Jurka <books(at)ejurka(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump exclusion switches and functions/types
Date: 2006-10-09 17:59:18
Message-ID: 4335.1160416758@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jim C. Nasby" <jim(at)nasby(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikolay Samokhvalov 2006-10-09 18:29:32 Re: Fwd: pg_dump VS alter database ... set search_path ...
Previous Message Chris Browne 2006-10-09 17:56:41 Re: OT: Is there a LinkedIn group for Postgresql?