Passing In Extra Input

Every check shares one signature — a single run-ID parameter — so there's no room for extra parameters of your own the way an ordinary function call would allow. Instead, use the framework's run-configuration table, which the collection engine already populates from its own optional parameters (the target PostgreSQL version, and the lists of tables to check with amcheck or pg_visibility) before it starts running any checks.

• Read it back inside your own check function with the framework's ready-made helper functions for pulling a specific key back out as an integer or a text array. See the built-in pg_upgrade-readiness checks (which read the target-version key) or the visibility-map checks (which read the pg_visibility table list) for real examples of the pattern.
• If your own parameter doesn't map onto one of the collection engine's existing optional arguments, insert your own row into the run-configuration table yourself, before calling the collection engine — this table isn't locked down the way the check catalog is, since it's scratch data scoped to one run, not part of the catalog.
• If missing configuration simply means the check doesn't apply, return a skipped result with a clear explanation (the same pattern the pg_upgrade-readiness checks use) rather than raising an error or guessing at a value.

Continue to Adding a Threshold.