Re: Patch for pg_dump: Multiple -t options and new -T option
От | Bruce Momjian |
---|---|
Тема | Re: Patch for pg_dump: Multiple -t options and new -T option |
Дата | |
Msg-id | 200407211417.i6LEHON23029@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Patch for pg_dump: Multiple -t options and new -T ("David F. Skoll" <dfs@roaringpenguin.com>) |
Ответы |
Re: Patch for pg_dump: Multiple -t options and new -T
|
Список | pgsql-patches |
David F. Skoll wrote: > Hi, > > This is a response to several messages: > > 1) Copyright notice: I have no problem having this removed, although it > would be nice to credit me somewhere in a comment. We credit in the commit message, and in the release notes so it will always be seen. > 2) I put most of the code in a separate file so that if the patch is > rejected, it's easy for me to maintain a forked copy. If the patch is > accepted, obviously it can be integrated into an existing file. OK. Makes sense. > 3) Multiple -n options: We need to figure out how this would work, and make > it non-surprising. Some ideas: > > pg_dump -t t1 -n s2 -t t2 -t t3 -n s4 -t t5 > > What does that do? My guess is: > > - Dump table t1 in any schema > - Dump tables t2 and t3 in schema s2 > - Dump table t5 in schema s4 > > So now the position of the options matters! That might surprise people, > because: > > pg_dump -s s1 -t t2 > > is no longer the same as: > > pg_dump -t t2 -n s1 > > What about: > > pg_dump -t t1 -n s2 > > Should that dump table t1 in any schema, and any table in schema s2? > > If we can nail down the semantics, I can implement the patch. The > code is very simple. Even though I suggested it, I am afraid this is just too confusing an API. And I can't think of another one. :-( -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: