| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | sai(dot)dulla(at)berkeley(dot)edu, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #15851: Concurrent Refresh of Materialized views not preserving the order of the underlying query |
| Date: | 2019-06-14 01:17:22 |
| Message-ID: | CAKJS1f9z0o6zxJ7=Au6K4kxVigkn_G6XC2NKtWB_YQAT0_qjSw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, 14 Jun 2019 at 12:29, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> A more aggressive approach would be to reject ORDER BY in the
> query defining a matview, but perhaps that's too in-your-face...
Yeah. I think if we'd thought about it at the time we'd probably have
rejected an ORDER BY in the view definition. Doing that today might
break pg_upgrade and pg_restore. Do you think there's any merit in a
WARNING during CREATE MATERIALIZED VIEW if the query has an ORDER BY?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Feike Steenbergen | 2019-06-14 08:26:35 | Re: BUG #15847: Running out of memory when planning full outer joins involving many partitions |
| Previous Message | David G. Johnston | 2019-06-14 00:47:10 | BUG #15851: Concurrent Refresh of Materialized views not preserving the order of the underlying query |