Re: track generic and custom plans in pg_stat_statements

On Tue, Jul 29, 2025 at 05:08:09PM -0500, Sami Imseih wrote:
> The only comment I have is I think we need a NOT_SET
> member, so it can simplify the life of extensions that have code
> paths which may or may not have a PlannedStmt, such as
> pgss_store.

Okay by me for having a default that maps to something else than the
rest.

+   PLAN_STMT_NOT_SET = 0,      /* origin not yet set */ 

The term "NOT_SET" makes me itch a little bit, even if there is an
existing parallel with OverridingKind.  Perhaps your proposal is OK,
still how about "UNKNOWN" instead to use as term for the default?

> In pgss_store, I don't want to pass the entire PlannedStmt,

Neither do I.

> nor do I want to pass PLAN_STMT_INTERNAL in the call during
> post_parse_analyze, in which case we don't have a plan.

Okay.
--
Michael