Re: Implicit rule created for materialized views

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Implicit rule created for materialized views
Дата
Msg-id CAHwBYSJ18fa-CnE-TrsDQU92ryMYtytW5dQsyJcd4ST6BTxLtg@mail.gmail.com
обсуждение исходный текст
Ответ на Implicit rule created for materialized views  (Dave Page <dpage@pgadmin.org>)
Список pgsql-hackers
Yes, that is currently used for REFRESH, and will be used to drive the incremental maintenance when that is added.  Without it, CREATE MATERIALIZED VIEW wouldn't be different from CREATE TABLE AS.

A materialized view is pretty much like a view, but with the results materialized.

-Kevin



On Mon, Jun 3, 2013 at 6:58 AM, Dave Page <dpage@pgadmin.org> wrote:
Hi

In playing with materialized views, I noticed that they still seem to
have an _RETURN rule implicitly created like a regular view. This
doesn't seem right to me - is there a reason?

viper:~ dpage$ /usr/local/pgsql-9.3/bin/psql -p 5433 -U postgres
psql (9.3beta1)
Type "help" for help.

postgres=# CREATE MATERIALIZED VIEW ruletest AS SELECT * FROM pg_class;
SELECT 298
postgres=# SELECT pg_get_ruledef(oid) FROM pg_rewrite WHERE ev_class =
'ruletest'::regclass;
                         pg_get_ruledef
-----------------------------------------------------------------
 CREATE RULE "_RETURN" AS                                       +
     ON SELECT TO ruletest DO INSTEAD  SELECT pg_class.relname, +
     pg_class.relnamespace,                                     +
     pg_class.reltype,                                          +
     pg_class.reloftype,                                        +
     pg_class.relowner,                                         +
     pg_class.relam,                                            +
     pg_class.relfilenode,                                      +
     pg_class.reltablespace,                                    +
     pg_class.relpages,                                         +
     pg_class.reltuples,                                        +
     pg_class.relallvisible,                                    +
     pg_class.reltoastrelid,                                    +
     pg_class.reltoastidxid,                                    +
     pg_class.relhasindex,                                      +
     pg_class.relisshared,                                      +
     pg_class.relpersistence,                                   +
     pg_class.relkind,                                          +
     pg_class.relnatts,                                         +
     pg_class.relchecks,                                        +
     pg_class.relhasoids,                                       +
     pg_class.relhaspkey,                                       +
     pg_class.relhasrules,                                      +
     pg_class.relhastriggers,                                   +
     pg_class.relhassubclass,                                   +
     pg_class.relispopulated,                                   +
     pg_class.relfrozenxid,                                     +
     pg_class.relminmxid,                                       +
     pg_class.relacl,                                           +
     pg_class.reloptions                                        +
    FROM pg_class;
(1 row)


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: UTF-8 encoding problem w/ libpq
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Optimising Foreign Key checks