Hi guys,
Cool. Thanks heaps. :)
We should be able to come up with something decent out of both your and
Neil's comments. :)
There's a lot of info between both of them, and it would be interesting
to know if the other main commercial databases track this properly. It
could be useful here and into the future as an example of where we do
stuff that's obviously safer+better than our commercial counterparts.
:-)
Regards and best wishes,
Justin Clift
Joe Conway wrote:
<snip>
> Well since the comment was really mine (and I hid behind Neil), I'll
> tell you what I was thinking and others can agree or shoot it down in
> flames ;-)
>
> The point is that in the absence of dependency tracking, there is
> nothing to prevent you from, for example, dropping a column that is used
> as a foreign key reference, or is included in a view. With dependency
> tracking, DROP COLUMN is a safer feature than it would have been,
> because you are prevented from shooting yourself in the foot. E.g.:
>
> test=# create table dep1(f1 int, f2 int);
> CREATE TABLE
> test=# create view vwdep as select f1,f2 from dep1 ;
> CREATE VIEW
> test=# alter table dep1 drop column f2;
> NOTICE: rule _RETURN on view vwdep depends on table dep1 column f2
> NOTICE: view vwdep depends on rule _RETURN on view vwdep
> ERROR: Cannot drop table dep1 column f2 because other objects depend on it
> Use DROP ... CASCADE to drop the dependent objects too
>
> HTH,
>
> Joe
>
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi