Philip Warner <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
