Re: pg_stat_statements: Fix nested tracking for implicitly closed cursors

On Tue, Jan 20, 2026 at 01:27:05PM -0800, Lukas Fittl wrote:
> Not sure if you already had a place in mind, but thinking through
> where we could attach it, I realized two things:
>
> 1) QueryDesc seems like a reasonable struct to communicate nesting
> level (since it gets passed to the relevant executor hooks already),
> but that doesn't get passed to ProcessUtility today
> 2) ProcessUtility has an existing indicator for top-level statements
> in ProcessUtilityContext (PROCESS_UTILITY_TOPLEVEL)
>
> Were you thinking of actually using a backend struct (i.e.
> PgBackendStatus) and keep changing that as we run through the
> different execution levels, and exposing a helper function to retrieve
> it?

I did not have in mind a backend structure with a state allocated for
as long as the session lives would be a good fit. It is a bit better
than a static flag to drive the decisions, but it is still open to
being incorrect because it would require more code paths to reset it.
Something like QueryDesc would be a better fit, for a state that
sticks for as long as a top-level transaction is running. We are not
doing that stuff really well yet, though, if we want to track data
like a nesting level. So my short answer is that I do not know yet
what a good answer is, but it is definitely a problem to have some
duplicated logic to calculate a nesting level across many extensions.
QueryDesc was one that popped in mind, like you, but I got reminded
that utility.c has no idea about that, so... Now QueryDesc knows
about a PlannedStmt, which is something that utility.c knows.
--
Michael