Re: BUG #13907: Restore materialized view throw permission denied

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: marian(dot)krucina(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13907: Restore materialized view throw permission denied
Date: 2016-06-16 07:28:45
Message-ID: CAB7nPqQFLsrHDG=+6R6jw7QG9e9drk5aPsBtzsVpGuaF3VrXtQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Jun 15, 2016 at 4:37 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Tue, Jun 14, 2016 at 10:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
>
> Ah, right! I forgot that views already solve this problem in its way,
> and that's definitely something that we should do.
>
> [code lookup]
>
> OK I see now how to wrap that. I'll come up with something that can be
> back-patched and think about the refactoring carefully.

So, I have been able to build the attached WIP patch proving that this
is able to work correctly. There is no real refactoring done yet, but
this passes regression tests and tutti-quanti. By the way, there are
three points I am wondering about:
1) EXPLAIN ANALYZE is able to work with CTAS and create matview. I am
thinking that it would be better not to touch those to not impact
existing applications. By that I mean that EXPLAIN CREATE MATVIEW WITH
NO DATA would still run the planner and executor in explain.c
2) CTAS has a WITH NO DATA option, and it would be really weird to use
the planner/executor code path when this option is used for this case.
So I'd like to use the same method for both matviews and normal
relations to simplify things and make the code more consistent.
3) In this WIP patch, the command tag is CREATE MATERIALIZED VIEW if
WITH NO DATA is used. I am planning to use SELECT 0 in all cases to
keep things consistent with what is on HEAD and back-branches.

Any objections to those points? If there are none, I'll move ahead
with a more intelligent and refactored patch.
--
Michael

Attachment Content-Type Size
matview-plan-wip.patch invalid/octet-stream 4.8 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hans Buschmann 2016-06-16 07:39:35 Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db
Previous Message Michael Paquier 2016-06-16 05:45:04 Re: Segmentation fault with postgres -C external_pid_file