> 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
