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
signature.asc
Description: PGP signature
