Skip site navigation (1) Skip section navigation (2)

Re: Patch for pg_dump: Multiple -t options and new -T option

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,"David F(dot) Skoll" <dfs(at)roaringpenguin(dot)com>,pgsql-patches(at)postgresql(dot)org
Subject: Re: Patch for pg_dump: Multiple -t options and new -T option
Date: 2004-07-20 12:18:48
Message-ID: 7462.1090325928@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
> One problem with this patch is that there's no way to dump multiple 
> tables in different schemas.  Does this matter?  It's a bit 
> non-orthogonal...

Yeah.  With the combination of -n and -t you can pull a specific table,
but as soon as you allow either switch to be multiple you've got an
inexact tool.

I had thought of allowing -t to be schema.table but I'm worried about
backwards-compatibility issues.  In particular, since we don't support
SQL-style quoting in -t arguments, how could one then select a table
name that actually contains a dot?  Or should we just write off that
case as "stupidity is its own reward"?  It would also be good to not
foreclose the possibility of wild-card matching patterns in these
switches in future.

(BTW, does the patch handle multiple -n switches?)

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: David F. SkollDate: 2004-07-20 12:23:46
Subject: Re: Patch for pg_dump: Multiple -t options and new -T
Previous:From: Simon RiggsDate: 2004-07-20 11:57:16
Subject: Re: PITR COPY Failure (was Point in Time Recovery)

pgsql-patches by date

Next:From: David F. SkollDate: 2004-07-20 12:23:46
Subject: Re: Patch for pg_dump: Multiple -t options and new -T
Previous:From: Simon RiggsDate: 2004-07-20 11:57:16
Subject: Re: PITR COPY Failure (was Point in Time Recovery)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group