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