At 11:23 27/06/00 -0400, Tom Lane wrote:
>Of course the DBA can run the restore utility
>more than once and extract a subset of tables each time, but I don't
>see how the restore utility can be expected to do that for him.
Only works with seek (ie. a file).
>Features that don't work all the time are not
>good in my book.)
The *only* bit that won't work is being able to select the table data load
order, and I can fix that by writing tables that are wanted later to /tmp
if seek is unavailable. This *may* not be a problem, and probably should be
presented as an option to the user if restoring from non-seekable media.
Assuming that the backup was originally written to seekable media, I will
be able to tell the user how much space will be required, which should help.
I don't suppose anyone knows of a way of telling if a file handle supports
seek?
>Basically I think we want to assume that pg_dump will write the tables
>in an order that's OK for restoring. If we can arrange for RI checks
>not to be installed until after all the data is loaded, this shouldn't
>be a big problem, seems like.
Part of the motivation for this utility was to allow DBAs to fix the
ordering at restore time, but otherwise I totally agree. Unfortunately I
don't think the RI checks can be delayed at this stage - can they?
I don't suppose there is a 'disable constraints' command? Or the ability to
set all constraints as deferrred until commit-time?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/