David F. Skoll wrote:
Ah, I see in TODO:

* Allow pg_dump to use multiple -t and -n switches

so the problem with lack of multiple -n parameters was already known.

Should we allow -n to affect subsequent -t parameters, so:

-n schema1 -t tab1 -n schema2 -t tab2

does schema1.tab1 and schema2.tab2?

--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) 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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

On Wed, 21 Jul 2004, Christopher Kings-Lynne wrote:

I'd also move the should_dump.c file into an existing file and make sure
the patch is against CVS HEAD, not 7.4.3.

Also, there's a copyright statement at the top, retaining copyright with
the author. Does anyone have an issue with that?

Gavin

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Gavin Sherry wrote:
Agreed.

Yes, no need for it. We discourage that.

--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) 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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

At 12:59 PM 21/07/2004, Bruce Momjian wrote:
Might be polite, not to mention legally required, to check with the author
of the patch first.


----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
and from pgp.mit.edu:11371 |/


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

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.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

David F. Skoll wrote:
We credit in the commit message, and in the release notes so it will
always be seen.

OK. Makes sense.

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 (AT) candle (DOT) 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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

On Wed, 21 Jul 2004, Bruce Momjian wrote:

How about this:

pg_dump -t t1 -- Dump table t1 in any schema
pg_dump -n s1 -- Dump all of schema s1
pg_dump -t t1 -n s1 -- Dump t1 in s1
pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2
pg_dump -t t1 -t t2 -n s1 -n s2 -- Dump s1.t1, s1.t2, s2.t1 and s2.t2

Basically, no "-t" option means dump all tables. No "-n" option
means dump all schemas. If any "-t" or "-n" options are present,
then we only dump the specified tables/schemas. We also probably
should not warn about missing tables, because it's likely that the
full cartesian product of schemas and tables won't exist.

And we nuke the -T and -N options.

Regards,

David.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

"David F. Skoll" <dfs (AT) roaringpenguin (DOT) com> writes:
Why not

pg_dump -t t1 -- Dump table t1 in any schema
pg_dump -n s1 -- Dump all of schema s1
pg_dump -t s1.t1 -- Dump t1 in s1
pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
pg_dump -t t1 -t t2 -n s1 -n s2 -- Dump s1.t1, s1.t2, s2.t1 and s2.t2

That is, the rules are:
- if any -t switches appear, only tables matching (any one of)
those switches are dumped
- if any -n switches appear, only objects in (any one of)
those schemas are dumped
- a -t switch can be name only or schema.name

The cross-product semantics you're proposing can't implement my fourth
example.

I really dislike the idea of switch ordering making a difference...

Agreed. If any -t or -n switches appear, then warn only if *no* objects
get selected.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

On Wed, 21 Jul 2004, Tom Lane wrote:

That's a good idea, but then it's questionable whether we need the -n
switch at all. It might be simpler to extend the -t switch to
accept:

pg-dump -t 's1.*'

rather than using a -n switch. Of course, that breaks
backward-compatibility.

Regards,

David.

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

"David F. Skoll" <dfs (AT) roaringpenguin (DOT) com> writes:
Sure we do --- for backwards compatibility if nothing else.

That would not be the same thing --- that would mean to dump *only tables*
from s1, rather than objects of all types. Anyway, I think it's a bit
late in this cycle to be proposing to implement wild-card matching.
Maybe for next time someone can do that, but for 7.5 I think we should
limit ourselves to cleaning up any design flaws of the already-submitted
patch.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings