At 09:29 AM 13/11/2002 -0500, Rod Taylor wrote:
>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.
Do we have a list of dependency data that we collect? eg. do we know about
functions used in views and indexes? At this stage it's probably worth
making a list of what we think is achievable in 7.4, and what we want to
achieve ultimately. I certainly agree about recombining function headers
and bodies, but there are a bunch of things that I think we can leave
deconstructed and always move to the end of the restore, eg:
- constraints
- sequences set (not really a dependency problem)
- indexes
- comments
AFAIR, we can only split function bodies for non-SQL functions.
For views we need to know the types of casts within the view, the types
returned by the view, the functions used by the view as well as the tables
referenced. AFAIR, there is no way to break up a view, so it has to go
after each ancestor.
For a table, it should be sufficient to know the constraints & types; we
can add constraints later, but I'd be reluctant to get into doing 'ALTER
TABLE ADD COLUMN...'.
Indexes may have a function and/or a cast? Create Index I on T( cast(id as
my_type) )?
I'd guess constraints can depend on multiple tables, views(?), types, &
functions. Not sure what else. We can't really break these down.
So it looks like the only contentious item might be table attrs? is that right?
----------------------------------------------------------------
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 |/
