> 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
> - constraints > - sequences set (not really a dependency problem) > - indexes > - comments I can make a complete list tonight of whats captured. Shall we tack the list onto the end of section 3.13 (pg_depend): http://developer.postgresql.org/docs/postgres/catalog-pg-depend.html > 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...'. Shouldn't ever need to do an ALTER TABLE ADD COLUMN. But I can certainly come up with a case for ALTER TABLE SET DEFAULT. > 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. They can via functions. And you can break down a function and table, but not really types or views. CREATE FUNCTION func .... 'SELECT TRUE;' LANGUAGE 'sql'; CREATE <items requiring function>; -- Fill in function body. CREATE OR REPLACE FUNCTION func ... '<real query>' LANGUAGE 'sql'; > So it looks like the only contentious item might be table attrs? is that right? More likely to be functions. As everything else (I can think of) is easily altered into place. -- Rod Taylor ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
