On Tue, Nov 17, 2009 at 03:54, Marko Tiikkaja <marko.tiikk...@cs.helsinki.fi> wrote: >> Also, after reading through the previous threads; it was not >> immediately obvious that you dealt with >> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00566.php by >> only allowing selects or values at the top level of with. > > This is actually just something missing from the current implementation. > The relevant posts are in the same thread:
> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00558.php and > the two follow-ups. The comment in ExecutePlan() is a bit misleading. Hrm I tried the various forms of: with x as ( ... ) insert/update/delete and could not get any of them to work. So I assumed the comment about only SELECT and values were allowed was correct. Maybe a function that does an insert or update at the top level could get it to break? > What I meant is that we don't call GetCurrentCommandId() in > standard_ExecutorStart(). Instead we get a new CID for every CTE with > INSERT/UPDATE/DELETE. That comment tried to point out the fact that > this strategy could fail if there was a non-SELECT query as the > top-level statement because we wouldn't increment the CID after the last > CTE. Right... Which I thought was more or less the recommendation? Guess Ill have to go re-read that discussion. > I did it this way because it works well for the purposes of this > patch and I didn't see an obvious way to determine whether we need a new > CID for the top-level statement or not. > > I'll send an updated patch in a couple of days. Peachy. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
