Re: pg_dump exclusion switches and functions/types

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 19:34:09
Message-ID: 20061009193409.GG72517@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 09, 2006 at 01:59:18PM -0400, Tom Lane wrote:
> "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.)

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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-10-09 19:35:46 Re: continuing daily testing of dbt2 against postgresql
Previous Message Tzahi Fadida 2006-10-09 19:31:14 Re: OT: Is there a LinkedIn group for Postgresql?