Re: pg_stat_statements stores WITH HOLD cursor query with literals

> That said, I'm still not convinced that using this extensibility for
> tracking nesting level is the best approach, vs figuring a way in-core
> to pass the current nesting level to executor hooks. It seems every
> extension re-invents this, and keeps copying the same mistakes, e.g.
> I'm sure pg_stat_monitor, pg_stat_kcache and pg_stat_plans will need
> to solve this same tracking problem that is being talked about in this
> thread.

One point raised is that the two contrib extensions that currently keep a
nesting_level, auto_explain and pg_stat_statements, do not give it quite the
same meaning. They both bump it around ExecutorRun and ExecutorFinish, but
pg_stat_statements also bumps it around the planner and ProcessUtility calls.

For auto_explain, nesting_level == 0 is used at ExecutorStart and ExecutorEnd
as part of its sampling, instrumentation and logging decisions. If that value
also counted utility or planning nesting, auto_explain would start treating
some currently top-level plans, such as CREATE TABLE AS queries, as nested.

So at least for these two contrib modules, preserving the current behavior
would seem to require keeping the nesting decision decoupled from a single
shared nesting_level.

Those differences could perhaps be worked around, but each extension would
still need to decide what the value means for its own purposes, so they may
still need some form of queryDesc state.

--
Sami Imseih
Amazon Web Services (AWS)