On Sun, Jan 18, 2026 at 7:18 PM Michael Paquier <[email protected]> wrote: > Hmm. While reading through the patch, I am wondering if this approach > to this kind of problem is the right thing to do long-term, relying on > a static flag to decide if the nesting level should be manipulated or > not when we end the executor. pgss is not the only module where I > have seen that we want to track a nesting level in a precise way. So > could be it more flexible to attach that to a backend structure at > this point and make manipulations of this number through the core > backend, reducing TRY/CATCH blocks required in extension code?
+1 I think tracking nesting level in core would make a lot of sense - I've noticed this too that extensions (pg_wait_sampling, pg_qualstats, pg_stat_plans, etc) seem to keep re-inventing this, and I assume the definition of this would be the same across extensions. 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? Thanks, Lukas -- Lukas Fittl
