| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | kardash(dot)a(dot)v(at)yandex(dot)ru, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, Kevin Grittner <kgrittn(at)gmail(dot)com> |
| Subject: | Re: BUG #13870: couldn't restore dump with mat view |
| Date: | 2016-01-22 12:37:49 |
| Message-ID: | CAB7nPqTYY+XgYi+q-hGcY-ePXWap4RaPRmteY=9ieh_Lfy=qsQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sun, Jan 17, 2016 at 12:27 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> point() is just fine, because check_relation_bodies is turned off.
> pg_dump does that specifically because it can't see into the function
> body to know what dependencies might be there.
Thanks. Missed that.
> The reason for separating dump/reload of matviews into two steps,
> CREATE ... WITH NO DATA followed by REFRESH, is again to guard against
> hidden dependencies. If the view were planned/executed only at the
> REFRESH stage, this dump script would be fine as-is. It's the attempt
> to avoid having two code paths in ExecCreateTableAs() that is causing
> this failure.
My brain is a bit fried now... But do you think that we could have
some additional logic in ExecCreateTableAs() using
check_relation_bodies?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitriy Sarafannikov | 2016-01-22 12:45:27 | Wal sender segfault |
| Previous Message | David G. Johnston | 2016-01-22 05:02:41 | Re: BUG #13880: Different procedures in same SQL |