Re: pg_dump in 7.4

At 02:53 PM 13/11/2002 -0500, Rod Taylor wrote:
>I can make a complete list tonight of whats captured.

Sounds good.

If you can also indicate which parts of functions are captured - arguments,
return type and body? IIRC, only SQL functions are compiled at define-time,
so other functions *shouldn't* be a major problem if they are out of order
in *most* cases.

Since pg_dump already has some intrinsic knowledge of dependencies, if
there is much missing from pg_depend, we could probably add it to pg_dump
(it many cases it will just be a matter of getting oids as well as names in
SQL statements).

In terms of supporting older dump files, I think it should all work: they
already have space for deps, mostly empty, and as Tom suggested, we should
be able to dump leaf nodes in OID order. From the PoV of pg_dump, the
algorthim becomes:

1. generate in-memory TOC in a convenient format.
2. pick the lowest OID *leaf* node. If none, goto 5.
3. remove it from deps of other TOC entries
4. goto 2.

[cyclic]
5. pick the lowest OID node. See if we can break it. If not repeat with
more nodes until we can break one. If none, then goto step 8.
6. Break up the node.
7. Goto 2.

[cyclic, no resolution]
8. Pick the lowest OID node.
9. Goto 3.

There are a few issues here:

(a) we need to know dependencies of *parts* of objects in order to do the
breakup. To me this implies we should break them up at dump time (ie. have
FUNCTION_DEFINITION and FUNCTION_BODY TOC entries; it gets nastier with
tables, but TABLE_DEFINITION, TABLE_CONSTRAINT, ATTRIBUTE_CONSTRAINT, and
ATTRIBUTE_DEFAULT come to mind. So time later we can write cunning code to
recombine them (volunteers?).

(b) Step 6 may be pointless. We probably need to verify that we will end up
with a leaf node as a result of the breakup: I presume someone has a good
algorithm. But if we do have a cycle, I'd guess we should just revert to an
OID ordering, since while we may pick the topologically optimal node, it
may well not be optimal from PostgreSQL point of view: if the node fails to
be defined, then everything else that depends on it will fail. This has the
advantage of being simple.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/