Re: pg_stat_statements stores WITH HOLD cursor query with literals

> One concern with a single shared field: extensions count nesting
> differently. auto_explain has no ProcessUtility hook, so when DECLARE
> starts the cursor's query, auto_explain is at level 0 while
> pg_stat_statements is at level 1.
>
> In my first repro (track = top), pg_stat_statements does not request
> instrumentation at level 1, so only auto_explain sets the field, to 0.
> pg_stat_statements would then read 0 in ExecutorEnd and still store
> the cursor query as top level. With track = 'all' both set it, and
> which value wins depends on which extension's hook runs first.

Good point, a single field can't hold two different ideas of what the
nesting level is.

> So pg_stat_statements probably needs to know whether it set the level
> itself, and skip the query when it did not. Would a per-extension slot,
> or a single nesting level tracked by core, work better here?

per-extension slot sounds a bit too heavy-handed for me. And I'd rather
not have core track the nesting level either, since core would have to
pick one definition for every extension, and extensions can
legitimately disagree on what counts as nesting.

So the attached v1 goes the simpler way. It adds a field called
start_nesting_level, which can be set at ExecutorStart by any extension
that counts nesting levels the way pg_stat_statements does. The comment
on the field spells out what that means, and an extension that counts
differently, like auto_explain, should just not set it, so v1 doesn't
change auto_explain at all.

There is precedent for this kind of field. Query.queryId and
PlannedStmt.planId are both core fields that "can be set by plugins",
and it's up to the plugins that set them to agree on what they mean.

Since every extension that sets it computes the same value, it doesn't
matter who sets it or in what order. And in your track = top case,
nobody sets the field, so pg_stat_statements skips the query.

v1 is a sketch of that without any tests yet. I will add if there is
agreement on
this being the way forward. This seems like the most straightforward way.
Maybe others have a different idea.

--
Sami Imseih
Amazon Web Services (AWS)