Re: Suggested enhancement to pg_restore

From: Michael Nolan <htfoot(at)gmail(dot)com>
To: Chris Travers <chris(dot)travers(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Suggested enhancement to pg_restore
Date: 2011-07-27 15:15:42
Message-ID: CAOzAquJac4C5JwzXj_NXrYPP_zn1JRz2SZfDGR3k--P+g7oftg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Jul 26, 2011 at 6:10 PM, Chris Travers <chris(dot)travers(at)gmail(dot)com>wrote:

> On Tue, Jul 26, 2011 at 3:48 PM, Michael Nolan <htfoot(at)gmail(dot)com> wrote:
> > I suggest adding the following parameter to pg_restore:
> >
> > --rename-table=XXXX
> >
> > When used in conjunction with the --data-only, --schema and -t options
> (all
> > three of which would be necessary),
> > it would allow restoring a table (without indexes) to a different table
> name
> > (which would need to already exist
> > and match the structure of the table which is being restored, of course.)
>
> Does pg_restore allow you to specify a set of tables the same way
> pg_dump does, i.e. by -t table1 -t table2?
>
> If so how would this feature play along?
>

Not sure, the man page for pg_restore seems to imply that -t can be used to
restore just ONE table,
though it also seems to say that pg_restore can be used to affect the order
in which the tables are restored.

If it can handle multiple -t entries, presumably they must all be in the
same schema, otherwise things
could get really confused if the same table name exists in more than one
schema.

If multiple -t entries are supported, I guess we would have two options.

1. Only allow one table to be restored using the --rename-table parameter
at a time.

2. Require that the command have matching pairs of -t and --rename-table
entries to make sure that the tables
are restored to the intended new names.

I don't have a major preference between these, though I suspect #1 would be
easier to implement.
--
Mike Nolan
nolan(at)tssi(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Karl Nack 2011-07-27 15:27:53 Re: Implementing "thick"/"fat" databases
Previous Message Greg Smith 2011-07-27 14:53:41 Re: heavy load-high cpu itilization