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@mindspring.com


Thu, 31 Aug 2000 12:56:03 -0400
Mark Hollomon <mhh@mindspring.com>
new relkind for view
Applied.

> 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@mindspring.com
> 
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 12 Sep 2000 00:49:19 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: new relkind for view
At 00:49 12/09/00 -0400, Bruce Momjian wrote:
>> 
>> o pg_dump
>> 

I've got to fix up a few things in pg_dump, so I'll try to do this as well...


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Tue, 12 Sep 2000 16:02:56 +1000
Philip Warner <pjw@rhyme.com.au>
Re: new relkind for view

In a continuing effort to make pg_dump produce valid SQL where possible, I
would like to move away from the 'Create Table'/'Create Rule' method of
defining views, and actually dump the 'Create View' command.

This seems quite do-able, but before I start I thought I would ask if there
were any reasons people could think of for not doing this?

The approach will be:

- when getting table info, also call pg_get_viewdef (which returns 'not a
view' for non-view relations).

- When dumping rules, ignore all 'view rules'. 

- Dump the 'Create View' statement in oid order as per normal.

It would be really nice if there was a simple way of detecting view rules
that was analagous to relkind. Is there a reason why this has not been
done? Has it been done?

Maybe the code that checks the rule name to see if it is a view could be
put in the backend?


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Thu, 14 Sep 2000 22:16:55 +1000
Philip Warner <pjw@rhyme.com.au>
Dumping views as views?
Philip Warner <pjw@rhyme.com.au> writes:
> - when getting table info, also call pg_get_viewdef (which returns 'not a
> view' for non-view relations).

Huh?  Just use the relkind to detect views.

			regards, tom lane

Thu, 14 Sep 2000 11:45:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Dumping views as views? 
At 11:45 14/09/00 -0400, Tom Lane wrote:
>Philip Warner <pjw@rhyme.com.au> writes:
>> - when getting table info, also call pg_get_viewdef (which returns 'not a
>> view' for non-view relations).
>
>Huh?  Just use the relkind to detect views.

Sorry; what the above means is that I will get the views when I get the
tables, and call 'pg_get_viewdef' in all cases. I will check relkind when I
come to dump the 'table'.

 
----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Fri, 15 Sep 2000 11:01:24 +1000
Philip Warner <pjw@rhyme.com.au>
Re: Dumping views as views? 