How can I confirm the effective managed PostgREST db-pre-request and db-pre-config settings on Supabase?

[7HERUBI7]

Hi,

I am performing a read-only security review of a managed Supabase staging project before enabling a server-side pg_cron + pg_net scheduler.

I am trying to determine the effective managed PostgREST configuration for:

• db-pre-config
• db-pre-request

I do not need or want to change any configuration.

What we have already verified:

• anonymous and authenticated Data API probes against schema "net" return:
  406 / PGRST106 / Invalid schema: net

• the authenticator role has no pgrst.* role-level override

• no application-accessible RPC, view, trigger, or known database bridge to net.* has been identified

• GraphQL has not provided a route to net.*

The remaining question is only:

How can a Supabase-hosted project owner verify whether the effective managed PostgREST process has db-pre-config or, if either is configured, obtain only the schema-qualified function name(s)?

If these values are not directly visible to users, is there a supported way to confirm either:

db-pre-config: unset
db-pre-request: unset

or, if configured, obtain only the schema-qualified function names?

I am not asking for credentials, JWTs, secrets, database passwords, or internal infrastructure details.

This is a read-only verification question. No configuration changes are desired.

Thanks.

[chris00234]

Short version: there's no endpoint or catalog view that exposes the effective config of the hosted PostgREST process. Both settings can come from env vars (PGRST_DB_PRE_CONFIG / PGRST_DB_PRE_REQUEST), which aren't visible to project owners. But you can verify them indirectly from inside the database, because PostgREST has to execute them there.

Where the values can come from (config docs):

• db-pre-request: env/config file, ALTER ROLE authenticator SET pgrst.db_pre_request, or a set_config('pgrst.db_pre_request', …) inside a pre-config function
• db-pre-config: env/config file (it names the function that does in-database config)

You've already ruled out the role-level path, so what's left is env vars and a pre-config function.

How they show up at runtime (from the PostgREST source):

• Pre-config is joined into the settings query PostgREST runs at startup and on every config reload: … FROM unnest($1) x JOIN <func>() _ ON TRUE (Config/Database.hs)
• Pre-request runs as its own statement, select <schema>.<func>(), inside every API transaction (Query/PreQuery.hs)

Both show up in pg_stat_statements, which is enabled by default on Supabase:

-- 1) PostgREST's config-loading query; a pre-config function would appear as "JOIN <func>() _ ON TRUE"
select userid::regrole, calls, query
from extensions.pg_stat_statements
where query ilike '%kv_settings%';

-- 2) Candidate pre-request calls: bare "select schema.func()" run as API roles
select userid::regrole, calls, query
from extensions.pg_stat_statements
where userid::regrole::text in ('anon', 'authenticated', 'service_role')
  and query ~* '^\s*select\s+[a-z0-9_."]+\s*\(\s*\)\s*$'
order by calls desc;

How to read the results:

• If query 1 returns the settings query and there's no JOIN …() _ ON TRUE in it, there's no pre-config function.
• If you've made Data API requests since the last stats reset and query 2 shows no select func() whose calls count tracks your request volume, there's no pre-request function.

Caveats:

• pg_stat_statements can be reset or evict entries, so "not found" is only meaningful if activity happened after the last reset. Check select stats_reset from extensions.pg_stat_statements_info;.
• The config query only runs at startup/reload. NOTIFY pgrst, 'reload config'; re-runs it without changing any setting, but skip it if you want zero side effects.
• If the query column shows <insufficient privilege>, run it as postgres.

For an authoritative answer about the platform defaults, a support ticket is the definitive route, but the above gives you evidence from the database itself.

[7HERUBI7]

Hi Chris,

Thank you very much for taking the time to answer my question in such detail.

Your explanation was especially helpful in clarifying how db-pre-config and db-pre-request can be observed indirectly through pg_stat_statements, even when the hosted PostgREST process configuration itself is not exposed.

I tested the approach you suggested on my staging project, and it gave useful additional evidence for our security assessment.

I really appreciate the precision of your response and the references to the PostgREST source code.

Thanks again for your help.