Peter Geoghegan <pe...@2ndquadrant.com> writes: > I merged upstream changes with the intention of providing a new patch > for you to review. I found a problem that I'd guess was introduced by > commit 9dbf2b7d75de5af38d087cbe2b1147dd0fd10f0a, "Restructure SELECT > INTO's parsetree representation into CreateTableAsStmt". This has > nothing to do with my patch in particular.
Yeah, I already deleted the intoClause chunk from the patch. I think treating SELECT INTO as a utility statement is probably fine, at least for now. > In the existing pg_stat_statements code in HEAD, there are 2 > pgss_store call sites - one in pgss_ProcessUtility, and the other in > pgss_ExecutorFinish. There is an implicit assumption in the extant > code (and my patch too) that there will be exactly one pgss_store call > per query execution. However, that assumption appears to now fall > down, as illustrated by the GDB session below. What's more, our new > hook is called twice, which is arguably redundant. That's been an issue right along for cases such as EXPLAIN and EXECUTE, I believe. Perhaps the right thing is to consider such executor calls as nested statements --- that is, the ProcessUtility hook ought to bump the nesting depth too. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers