new relkind for view

From: Mark Hollomon <mhh(at)mindspring(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: new relkind for view
Date: 2000-08-31 16:56:03
Message-ID: 20000831125603.B26005@mindspring.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

NB: I will be on vacation from 1-Sep to 5-Sep

On the patches list I sent the following:
-----------------------------------------

This patch implements a different "relkind"
for views. Views are now have a "relkind" of
RELKIND_VIEW instead of RELKIND_RELATION.

Also, views no longer have actual heap storage
files.

The follow changes were made

1. CREATE VIEW sets the new relkind

2. The executor complains if a DELETE or
INSERT references a view.

3. DROP RULE complains if an attempt is made
to delete a view SELECT rule.

4. CREATE RULE "_RETmytable" AS ON SELECT TO mytable DO INSTEAD ...
1. checks to make sure mytable is empty.
2. sets the relkind to RELKIND_VIEW.
3. deletes the heap storage files.

5. LOCK myview is not allowed. :)

6. the regression test type_sanity was changed to
account for the new relkind value.

7. CREATE INDEX ON myview ... is not allowed.

8. VACUUM myview is not allowed.
VACUUM automatically skips views when do the entire
database.

9. TRUNCATE myview is not allowed.

THINGS LEFT TO THINK ABOUT

o pg_views

o pg_dump

o pgsql (\d \dv)

o Do we really want to be able to inherit from views?

o Is 'DROP TABLE myview' OK?

--
Mark Hollomon
mhh(at)mindspring(dot)com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florent Guillaume 2000-08-31 17:50:45 UNION/INTERSECT in subselects
Previous Message Vince Vielhaber 2000-08-31 16:44:33 bitwise AND?