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
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 |