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