Michael Paquier <mich...@paquier.xyz> writes: > I got to wonder lately if we should not have a static state like what > we do for MyXactFlags to track down if a utility query is a top-level > one or not as most of the time we just want to check the flag as > passed down by standard_ProcessUtility(). I have faced this problem > as well lately when pushing down a PreventInTransactionBlock() for > some stuff with REINDEX for example. Not sure how reliable this would > be though.. Passing isTopLevel down the road is a no-brainer, and > perhaps having a static value would create more problems than it > solves in practice.
Hm. I suppose you'd need a PG_TRY block to ensure that the setting got restored correctly after an error, so maintaining it that way would be rather expensive. Also it just doesn't seem like transaction-wide state, so having a static for it feels like the wrong thing. [thinks for awhile...] Would it make any sense to mark Portals as being top-level or not, and then code that needs this info could look to "ActivePortal->isTopLevel"? We are already paying the PG_TRY overhead to maintain the ActivePortal variable safely. I'm not sure though whether the Portal is granular enough. Do we set up a separate Portal for subcommands? In the big scheme of things, though, we don't need this info in so many places that passing it down as a parameter is an undue burden. regards, tom lane