Re: BUG #13907: Restore materialized view throw permission denied
От | Tom Lane |
---|---|
Тема | Re: BUG #13907: Restore materialized view throw permission denied |
Дата | |
Msg-id | 22633.1465910990@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #13907: Restore materialized view throw permission denied (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: BUG #13907: Restore materialized view throw permission denied
|
Список | pgsql-bugs |
Michael Paquier <michael.paquier@gmail.com> writes: > This is one of those issues where it would be cool to only plan and > execute the query creating the materialized view query with NO DATA > without planning and executing it first, and do the actual planning > and execution at the first refresh. A similar problem was discussed > here: > https://www.postgresql.org/message-id/flat/20160115175546.2968.6033%40wrigleys.postgresql.org#20160115175546.2968.6033@wrigleys.postgresql.org > Thought I don't think that it is that straight-forward, the relation > defined using a CTAS uses column information directly derived from the > query planned, so the fix would be to extract the necessary > information for those columns: collation, column name, type OID and > typemod without the need of the existing routines. I think you want to be looking at the way that CREATE VIEW accomplishes the same task. See DefineView and DefineVirtualRelation. It might be worth refactoring those a bit to allow code sharing. regards, tom lane
В списке pgsql-bugs по дате отправления: