Re: Patch for pg_dump: Multiple -t options and new -T
От | David F. Skoll |
---|---|
Тема | Re: Patch for pg_dump: Multiple -t options and new -T |
Дата | |
Msg-id | Pine.LNX.4.58.0407211003450.8830@shishi.roaringpenguin.com обсуждение исходный текст |
Ответ на | Re: Patch for pg_dump: Multiple -t options and new -T option (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Patch for pg_dump: Multiple -t options and new -T option
|
Список | pgsql-patches |
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. 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. 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. 4) The -T option (and, one assumes, a corresponding -N option) If the -T option is considered unknown/risky and would prevent the patch from going in, we can drop it for now. Regards, David.
В списке pgsql-patches по дате отправления: