Thread: new relkind for view
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 orINSERT references a view. 3. DROP RULE complains if an attempt is madeto 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 relkindto RELKIND_VIEW.3. deletes the heap storage files. 5. LOCK myview is not allowed. :) 6. the regression test type_sanity was changed toaccount 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 entiredatabase. 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
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, Pennsylvania19026
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 |/
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 |/
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
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 |/