On Wed, 2002-11-13 at 09:08, Philip Warner wrote: > At 08:52 AM 13/11/2002 -0500, Rod Taylor wrote: > >The biggest trick will be trying to re-combine the ALTER ... ADD > >CONSTRAINT and ALTER ... SET DEFAULT statements back into CREATE TABLE > > I'm not sure this would be worth the effort - I'll grant it would be cute, > but getting pg_dump to understand SQL seems a little ambitious. We'd > probably end up defining a portable schema definition language just for > dump files.
> To achieve Tom's suggestion it might be simpler to store two versions - the > 'full' version, and the 'fully deconstructed' version. If our analysis of > the dependencies meant we needed to break up an object, then we use the > latter. Different approaches to the same result. To me, the dependency tree is already (mostly) broken up to start with. So at some point you need to teach something to re-combine in the pg_attrdef -> pg_class dependencies among others. But the opposite approach of starting with the large objects and breaking up where required would be just as good, especially if you only breakup the little bits that are required. Starting with all functions broken up into their two parts (definition and body) with the body dependent on the definition and recombining later if they sort side by side seems much easier than trying to resolve cycles and break it up at a later time. An ALAP scheduling algorithm will almost always sort these things to be side by side to allow combining on a second pass by something with the intelligence. -- Rod Taylor ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org