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  (David Fetter <david@fetter.org>)
Список 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 по дате отправления:

Предыдущее
От: Tzahi Fadida
Дата:
Сообщение: Re: OT: Is there a LinkedIn group for Postgresql?
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: continuing daily testing of dbt2 against postgresql