pg_restore -t table concerns
Hey hackers,
I have a few concerns with the usability and documentation for
pg_restore (note: I'm on 8.3, but I've checked the documentation for 8.4).
In my attempts to restore a table (using -t) from a backup file with -v
(verbose) selected, I noticed a few things:
1. If a non-existent table is used, e.g., "-t idontexist" no warnings
are thrown. (It took me a while to figure out why a table was not
being restored, since no warnings were issued.)
2. It appears that the -t (table) option does not allow full table
names, such as "myschema.mytable", however this is not stated in
the documentation for -t table. Is it possible to allow -t table
to accept [schema.]table qualifiers? If not, the documentation
should at least suggest that "-n namespace" be used to specify the
schema where the table resides.
3. It appears the the default for -n namespace uses the default_path
variable (typically "public"). However, I'm only guessing this
based on the behaviour, and it isn't mentioned in the
documentation for -n namespace.
Thanks for any input, and apologies if this has already been discussed.
-Mike
Mike Toews <mwtoews@sfu.ca> writes:
I have a few concerns with the usability and documentation for
pg_restore (note: I'm on 8.3, but I've checked the documentation for 8.4).
There's a TODO item about that already...
* Add support for multiple pg_restore -t options, like pg_dump
pg_restore's -t switch is less useful than pg_dump's in quite a
few ways: no multiple switches, no pattern matching, no ability
to pick up indexes and other dependent items for a selected
table. It should be made to handle this switch just like pg_dump
does.
regards, tom lane
Tom Lane wrote:
Mike Toews <mwtoews@sfu.ca> writes:
I have a few concerns with the usability and documentation for
pg_restore (note: I'm on 8.3, but I've checked the documentation for 8.4).There's a TODO item about that already...
* Add support for multiple pg_restore -t options, like pg_dump
pg_restore's -t switch is less useful than pg_dump's in quite a
few ways: no multiple switches, no pattern matching, no ability
to pick up indexes and other dependent items for a selected
table. It should be made to handle this switch just like pg_dump
does.
It should also be pointed out that there is a workaround using the
--use-list option.
cheers
andrew