From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump ordering |
Date: | 2003-08-02 03:07:43 |
Message-ID: | 18659.1059793663@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> In terms of the dependency data, I was planning to dump dependencies as
> well (a trivial skeleton exists); the ordering should happen at
> restore-time (except dump should store it in useful-order on the assumption
> that it will not be possible to re-order at restore-time).
ISTM that once we have the dependency problem sorted out, the important
ordering will always happen during dump, and the facility for
re-ordering during restore will become vestigial. This is a good thing,
since there are many scenarios where you can't seek backwards.
> This is important since we need to allow requests like:
> "restore table xyz and it's dependencies from a full dump"
Right. What will be needed instead will be the ability to know when we
are passing over object X in the dump that we must restore it, because
the object Y that we were asked to restore depends directly or
indirectly on it. So all the dependency info must appear at the front.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-08-02 03:34:03 | Re: psql \encoding fixed |
Previous Message | Tom Lane | 2003-08-02 02:55:41 | Re: psql \encoding fixed |