From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Justin Clift <justin(at)postgresql(dot)org> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Advocacy and Marketing Mailing List <pgsql-advocacy(at)postgresql(dot)org> |
Subject: | Re: [Fwd: Questions on 7.3 version for LinuxWorld] |
Date: | 2002-12-09 07:18:26 |
Message-ID: | 3DF443C2.8070406@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
Justin Clift wrote:
> Hi Neil,
>
> One of Nadia's points is:
>
> "In the release, Neil Conway comments that the new version contains a
> dependency tracking systems "that allows PostgreSQL to safely support
> many more subtle enhancements like the ability to drop columns". I'm
> unclear on the use of "safely" here - would you be able to elaborate on
> this comment further?"
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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Clift | 2002-12-09 07:24:19 | Re: [Fwd: Questions on 7.3 version for LinuxWorld] |
Previous Message | Neil Conway | 2002-12-09 07:18:23 | Re: [Fwd: Questions on 7.3 version for LinuxWorld] |