Re: Feature: temporary materialized views

On 2/5/19 6:56 PM, Andreas Karlsson wrote:
> On 2/5/19 12:36 PM, Michael Paquier wrote:> - skipData is visibly always 
> false.
>  > We may want to keep skipData to have an assertion at the beginning of
>  > inforel_startup for sanity purposes though.
> This is not true in this version of the patch. The following two cases 
> would crash if we add such an assertion:
> 
> EXPLAIN ANALYZE CREATE TABLE foo AS SELECT 1 WITH NO DATA;
> 
> and
> 
> PREPARE s AS SELECT 1;
> CREATE TABLE bar AS EXECUTE s WITH NO DATA;
> 
> since they both still run the setup and tear down steps of the executor.
> 
> 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?

In general I do not like how EXPLAIN CREATE TABLE AS uses a separate 
code path than CREATE TABLE AS, because we get weird but mostly harmless 
edge cases like the below and that I do not think that EXPLAIN ANALYZE 
CREATE MATERIALIZED VIEW sets the security context properly.

I am not sure if any of this is worth fixing, but it certainly 
contributed to why I thought that it was hard to design a good API.

postgres=# EXPLAIN ANALYZE CREATE TABLE IF NOT EXISTS bar AS SELECT 1;
                                      QUERY PLAN 

------------------------------------------------------------------------------------
  Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.001..0.002 
rows=1 loops=1)
  Planning Time: 0.030 ms
  Execution Time: 12.245 ms
(3 rows)

Time: 18.223 ms
postgres=# EXPLAIN ANALYZE CREATE TABLE IF NOT EXISTS bar AS SELECT 1;
ERROR:  relation "bar" already exists
Time: 2.129 ms

Andreas