Re: Backend-internal SPI operations
От | Tom Lane |
---|---|
Тема | Re: Backend-internal SPI operations |
Дата | |
Msg-id | 19786.967647953@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Backend-internal SPI operations (Jan Wieck <janwieck@Yahoo.com>) |
Список | pgsql-hackers |
Jan Wieck <janwieck@Yahoo.com> writes: > From memory I think views are created as CREATE TABLE, with > an internal DefineRuleStmt, and dumped as CREATE TABLE, > CREATE RULE for sure. So the CREATE/DROP RULE would need to > remove/recreate the tables file (plus toast file and index) > if you want it to be consistent. Don't think you want that - > do you? But that's only true because it's such a pain in the neck for pg_dump to discover that a table is a view. If this could easily be told from inspection of pg_class, then it'd be no problem to dump views as CREATE VIEW statements in the first place --- obviously better, no? However the initial version upgrade would be a problem, since dump files out of existing releases would contain CREATE TABLE & RULE commands instead of CREATE VIEW. I guess what would happen is that views reloaded that way wouldn't really be views, they'd be tables with rules attached. Grumble. How about this:CREATE RULE of an on-select-instead rule changes table'srelkind to 'view'. We don't need to drop the underlyingtablefile, though (just leave it be, it'll go away atnext initdb). DROP RULE of a view's on-select-instead is not allowed.You have to drop the whole view instead. regards, tom lane
В списке pgsql-hackers по дате отправления: