Mike Mascari <mascarm@mascari.com> writes:
> Now back to pg_dump. Since the temporary solution to eliminating
> dependency problems is to dump in OID order, with the current
> code, things won't break. But with an ALTER FUNCTION, dumping in
> OID order could very well break the schema:
Yes, that's been understood all along to be the weak spot of dumping
in OID order. But you can already break dump-in-OID-order with
existing commands like ALTER TABLE ADD CONSTRAINT. I think that the
advantages of ALTER FUNCTION are well worth the slightly increased risk
of dump/reload difficulties.
> 2) Change pg_dump to walk through dependencies?
The trouble with that is that dependency analysis is a monstrous job,
and one that would make pg_dump even more fragile and backend-version-
dependent than it is now. Besides, with ALTER it is possible to create
*circular* dependencies, so even after you'd done the work you'd still
not have a bulletproof solution, just a 99.9% solution instead of a 99%
solution. (Exact numbers open to debate, obviously, but you see my
point.)
> 3) Or devise a manner by which pg_dump can dump objects in a
> certain sequence such that dependencies never break?
If you've got one, step right up to the plate and swing away ;-).
You might be on the right track with the notion of creating functions
with dummy bodies and then doing ALTER later. I haven't thought it
through in detail, but maybe something based on that attack could work.
regards, tom lane
