Re: pg_dump in 7.4 - Mailing list pgsql-hackers

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   |/