Michael Paquier <michael@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
