Re: pg_stat_statements stores WITH HOLD cursor query with literals

On Thu, Oct 15, 2026 at 10:36:06AM +0530, Gaurav Singh wrote:
> I think the issue has existed since PG18, could we have a backpatch too?

With a change in QueryDesc? I'm afraid not.

+ /*
+ * Nesting level at which this query started, or -1 if not set. An
+ * extension may set this from its ExecutorStart hook and read it back at
+ * ExecutorEnd, which can run at a different level. For example, a
+ * cursor's query starts inside DECLARE but may end at COMMIT.
+ *
+ * The level counts as pg_stat_statements does: 0 for a statement sent by
+ * the client, including EXECUTE of a prepared statement; one deeper for
+ * each query run by another statement or by a function. All extensions
+ * that set this field must use that definition; one that counts
+ * differently must leave it alone.
+ */
+ int start_nesting_level;

This is a one-time extension field, tied exclusively to PGSS that may
or may not conflict depending on what other extensions do. This does
not give me good vibes in terms of extensibility, due to the easy
conflicts with other extensions.

We have a similar concept for ExplainState with its extension_state
indexed by GetExplainExtensionId() based on an extension name.
Perhaps we should do something similar for QueryDesc? That would take
care of the conflicting states across extensions at least, giving
extensions way to store in the QueryDesc what they want. Here, that's
the nesting_level that you want to track *only* in PGSS and have no
other extensions meddle with it.
--
Michael