Jan Wieck wrote:
>
> Mark Hollomon wrote:
> > But I could be mistaken.
>
> Yep, you are.
D'oh.
> So far about history, now the future.
>
> Dumping views as CREATE VIEW is cleaner. It is possible now,
> since we dump the objects in OID order. So I like it. I see
> no problem with Tom's solution, changing the relkind and
> removing the files at CREATE RULE time for a couple of
> releases. And yes, dropping the SELECT rule from a view must
> be forbidden. As defining triggers, constraints and the like
> for them should be.
Alright. To recap.
1. CREATE VIEW sets relkind to RELKIND_VIEW
2. CREATE RULE ... AS ON SELECT DO INSTEAD ... sets relkind to RELKIND_VIEWand deletes any relation files.
q: If we find an index, should we drop it, or complain, or ignore it? q: Should the code check to see if the relation
isempty (no valid tuples)?
3. DROP RULE complains if dropping the select rule for a view.
4. ALTER TABLE complains if run against a view.
Anything else?
--
Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008