From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alessio Bragadini <alessio(at)albourne(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: A problem with pg_dump? |
Date: | 2001-05-03 14:33:43 |
Message-ID: | 24383.988900423@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alessio Bragadini <alessio(at)albourne(dot)com> writes:
> It should work fine if rows would be dumped according to oid. Can this
> be considered a bug?
No; or at least, that solution would be equally buggy. It's not much
harder than your given example to construct cases where dumping the rows
in OID order would be wrong too (just takes some UPDATEs). In fact, I
could easily build a version of your table in which there is a circular
chain of dependencies and so *no* dump order will work.
pg_dump scripts ordinarily turn off foreign-key checking while loading
data, and this sort of consideration is the reason why. It looks to me
like you may have some pre-release copy of pg_dump that gets this wrong
(the comment format in your example is not exactly like current pg_dump,
which seems suspicious). Try pg_dump -V to see what it says.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alessio Bragadini | 2001-05-03 14:50:15 | Re: A problem with pg_dump? |
Previous Message | Peter Eisentraut | 2001-05-03 14:04:59 | Re: Unix sockets connection authentication - patch |