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(at)nortelnetworks(dot)com
ESN 451-9008 (302)454-9008