Re: Materialized views WIP patch
От | Noah Misch |
---|---|
Тема | Re: Materialized views WIP patch |
Дата | |
Msg-id | 20130714204526.GB11636@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Materialized views WIP patch (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Materialized views WIP patch
|
Список | pgsql-hackers |
While doing some post-commit review of the 9.3 materialized view feature, I noticed a few loose ends: On Thu, Jan 24, 2013 at 01:09:28PM -0500, Noah Misch wrote: > Note that [...] "ALTER TABLE ... RENAME CONSTRAINT" [is] > currently supported for MVs by ALTER TABLE but not by ALTER MATERIALIZED VIEW. > > There's no documented support for table constraints on MVs, but UNIQUE > constraints are permitted: > > [local] test=# alter materialized view mymv add unique (c); > ALTER MATERIALIZED VIEW > [local] test=# alter materialized view mymv add check (c > 0); > ERROR: "mymv" is not a table > [local] test=# alter materialized view mymv add primary key (c); > ERROR: "mymv" is not a table or foreign table The above points still apply. Also, could you explain the use of RelationCacheInvalidateEntry() in ExecRefreshMatView()? CacheInvalidateRelcacheByRelid() followed by CommandCounterIncrement() is the typical pattern; this is novel. I suspect, though, neither is necessary now that the relcache does not maintain populated status based on a fork size reading. Thanks, nm -- Noah Misch EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: