Re: [HACKERS] CTE inlining - Mailing list pgsql-hackers

From Joe Conway
Subject Re: [HACKERS] CTE inlining
Date
Msg-id 3f4835a9-9bb2-d34d-faa7-e3afc8d87614@joeconway.com
Whole thread Raw
In response to Re: [HACKERS] CTE inlining  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [HACKERS] CTE inlining  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
On 05/04/2017 10:33 AM, Alvaro Herrera wrote:
> I'm not sure what your point is.  We know that for some cases the
> optimization barrier semantics are useful, which is why the proposal is
> to add a keyword to install one explicitely:
>
>          with materialized r as
>          (
>             select json_populate_record(null::mytype, myjson) as x
>             from mytable
>          )
>          select (x).*
>          from r;
>
> this would preserve the current semantics.

I haven't been able to follow this incredibly long thread, so please
excuse me if way off base, but are we talking about that a CTE would be
silently be rewritten as an inline expression potentially unless it is
decorated with some new syntax?

I would find that very disconcerting myself. For example, would this CTE
potentially get rewritten with multiple evaluation as follows?

DROP SEQUENCE IF EXISTS foo_seq;
CREATE SEQUENCE foo_seq;

WITH a(f1) AS (SELECT nextval('foo_seq'))
SELECT a.f1, a.f1 FROM a;f1 | ?column?
----+---------- 1 |        1
(1 row)

ALTER SEQUENCE foo_seq RESTART;
SELECT nextval('foo_seq'), nextval('foo_seq');nextval | ?column?
---------+----------      1 |        2
(1 row)

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] CTE inlining
Next
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] CTE inlining