Re: Backend-internal SPI operations

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_VIEW
	and 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 is empty (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