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 |
Date: | 2019-02-06 09:18:17 |
Message-ID: | 20190206091817.GB14980@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
> below?
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?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
ctas-nodata-tests.patch | text/x-diff | 3.2 KB |
From | Date | Subject | |
---|---|---|---|
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 |