On Wed, Oct 16, 2013 at 4:26 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Moshe Jacobson <moshe@xxxxxxxxxxxx> writes: >> However, It behaves as one would expect if the first CTE is built with INSERT >> ... RETURNING. > > CTEs containing INSERT/UPDATE/DELETE are guaranteed to be executed exactly > once. CTEs containing SELECTs are guaranteed to be executed at most once > (the documentation phrases that as "execution can stop early if the outer > query doesn't read all the rows" --- in this case, it read none of them, > since the outer query never had to evaluate the NOT IN). > > I see no bug here. You can force the CTE to be read a couple of different ways; it isn't very difficult to do: just tweak the final query so that it *must* touch the SELECT result somehow (e.g. AND (SELECT COUNT(*) FROM tt_created) > 0). That being said, I do think it might be better behavior (and still technically correct per the documentation) if volatile query expressions were force-evaluated. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
