Brent Verner writes:
> | The more general question is: Should 'pg_dump -t table' dump all objects
> | that "table" depends on? Keep in mind that this could mean you have to
> | dump the entire database (think foreign keys). In my mind, dumping an
> | arbitrary subset of dependencies is not a proper solution, though.
>
> Do you care to share your ideas on what a proper solution /would/ be?
Either all dependencies or no dependencies would be a "proper" solution,
in my mind. Which one we should use is not obvious, that's why I stated
that question.
When you think about it, dumping the dependencies turns out to be less
useful than it seems at first. Since any object can be a dependency for
more than one object it would not work in general to do
pg_dump -t table1 > out1
pg_dump -t table2 > out2
psql -f out1
psql -f out2
unless you mess with CREATE OR REPLACE, which we don't have for all
objects and which would probably not be possible to execute in all
situations.
So the only real use for "dump object X and all dependencies" would be to
extract a functional subset of one database into another. But that seems
to be a lot less common operation.
Therefore I think that we should go with "no dependencies" (which is also
a lot easier, no doubt).
(Whether we should consider serial columns to be a dependency or an
integral part is a different question.)
--
Peter Eisentraut peter_e@gmx.net