From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Cascade delete views? |
Date: | 2000-09-19 15:55:38 |
Message-ID: | 6521.969378938@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> create table test (f1 int);
> create view v_test as select f1+1 as f11 from test;
> drop table test;
> create table test (f1 int);
> select * from v_test;
> ERROR: has_subclass: Relation 19417 not found
> which not very helpful for the person who does not know the history, and
> leads me to believe that there may be a few issues here.
Yes, this mistake needs to be detected earlier. The stored view
contains both the name and the OID of the referenced table. It should
*not* accept a new table with same name and different OID, since there's
no guarantee that the new table has anything like the same column set.
(ALTER TABLE has some issues here too...)
> Should a 'DROP TABLE' drop the views, fail, or be recoverable from by
> recreating the table?
Yes ;-).
Any of those behaviors would be better than what we have now. However,
none of them is going to be easy to implement. There will need to be
more info stored about views than there is now.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-09-19 16:13:06 | Re: Re: pg_dump tries to do too much per query |
Previous Message | Tom Lane | 2000-09-19 15:26:52 | Re: odbc (was: Re: ascii to character conversion in postgres) |