|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Andreas Karlsson <andreas(at)proxel(dot)se>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mitar <mmitar(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Feature: temporary materialized views|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, Feb 05, 2019 at 06:56:00PM +0100, Andreas Karlsson wrote:
> I guess that I could fix that for the second case as soon as I understand
> how much of the portal stuff can be skipped in ExecuteQuery(). But I am not
> sure what we should do with EXPLAIN ANALYZE ... NO DATA. It feels like a
> contraction to me. Should we just raise an error? Or should we try to
> preserve the current behavior where you see something like the
This grammar is documented, so it seems to me that it would be just
annoying for users relying on it to throw an error for a pattern that
simply worked, particularly if a driver layer is using it.
The issue this outlines is that we have a gap in the tests for a
subset of the grammar, which is not a good thing.
If I put Assert(!into->skipData) at the beginning of intorel_startup()
then the main regression test suite is able to pass, both on HEAD and
with your patch. There is one test for CTAS EXECUTE in prepare.sql,
so let's add a pattern with WITH NO DATA there for the first pattern.
Adding a second test with EXPLAIN SELECT INTO into select_into.sql
also looks like a good thing.
Attached is a patch to do that and close the gap. With that, we will
be able to check for inconsistencies better when working on the
follow-up patches. What do you think?
|Next Message||Arseny Sher||2019-02-06 09:21:27||Re: Too rigorous assert in reorderbuffer.c|
|Previous Message||Andres Freund||2019-02-06 09:17:40||Re: fast defaults in heap_getattr vs heap_deform_tuple|