Re: pg_stat_statements stores WITH HOLD cursor query with literals

On Tue, Oct 27, 2026 at 12:23 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > One could argue which behavior we want to see in the above, but I think
> > the point is that this QueryDesc state support could help us close some
> > of these issues.
>
> I don't really want to enter in the realm where we add more
> per-extension fields in backend structures, especially if multiple
> extensions have a risk of stepping on each other.
>
> > As far as v3- goes, they both look good to me, and I could not find
> > anything wrong with them.
>
> Okay, thanks. Let's use this infrastructure, then. I suspect that
> Lukas Fittl would also find uses for it, as he's a lot into monitoring
> and, err.. analyzing. I am adding him in CC to make him aware of this
> thread, at least, with QueryDesc extensibility in mind.

Thanks! I was actually briefly discussing this with Sami at PGConf.EU
last week, so I had already skimmed this :)

In general the extensibility seems helpful (I was briefly worried
about memory overhead / cache line impact, but even if another use
case adds more fields the increase is probably fine for QueryDesc
since it only exists once per query), though I don't have an immediate
use case for it in the extensions I'm working on.

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.

AFAIK we had discussed this previously on a different thread, but I'm
not clear on why we couldn't have one nesting level definition for all
of these extensions?

Thanks,
Lukas

--
Lukas Fittl