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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Tripp
Дата:
Сообщение: Re: BUG #14150: Attempted to delete invisible tuple
Следующее
От: gabrimonfa@gmail.com
Дата:
Сообщение: BUG #14188: "FOR SELECT DISTINCT, ORDER BY expressions must appear IN SELECT list" error and table alias