Re: pg_dump in 7.4

> 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