Re: BUG #13907: Restore materialized view throw permission denied
От | Michael Paquier |
---|---|
Тема | Re: BUG #13907: Restore materialized view throw permission denied |
Дата | |
Msg-id | CAB7nPqR-r8HMhEtEkGTr-N4kVrAJLqj-OP0wyjVin0U0BWsu5A@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #13907: Restore materialized view throw permission denied (marian.krucina@gmail.com) |
Ответы |
Re: BUG #13907: Restore materialized view throw permission denied
|
Список | pgsql-bugs |
On Tue, Feb 2, 2016 at 7:14 PM, <marian.krucina@gmail.com> wrote: > restore (9.4.5, 9.5.0) or pg_upgrade (9.4.5 to 9.5.0) fail on CREATE > MATERIALIZED VIEW. > This is similar to: > http://www.postgresql.org/message-id/11166.1424357659@sss.pgh.pa.us > > Problem is, when view runs as user definer. > Is possible move 'CREATE MATERIALIZED VIEW' in a dump to end? 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. -- Michael
В списке pgsql-bugs по дате отправления: