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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
