Dispatches /rpc/<fn> calls across the function return kinds PostgREST
supports: set-of-relation, set-of-scalar, scalar, scalar array, composite,
record / TABLE / OUT-params, void, and the special single-unnamed-parameter
functions whose argument is the raw request body (scalar / json).
Resolution mirrors PostgREST:
- the function is looked up in the
Accept-Profile/Content-Profileschema (overloads are dispatched by the supplied argument names); - GET/HEAD invoke STABLE/IMMUTABLE procs as reads (a VOLATILE proc raises
25006inside the read-only transaction and maps to 405); - POST binds args from the JSON body (an array body binds only its first object); a single unnamed json/jsonb parameter receives the whole body;
- unsupported methods (PATCH/PUT/DELETE) are rejected with PGRST101 (405);
- an unresolvable proc/signature returns PGRST202 (404) with PostgREST's
hint/details (reported against the base
testschema for area mirrors).
Content negotiation runs first (Bier.Negotiation), so an Accept that no
producer can satisfy yields 406 / PGRST107 before any SQL runs.
Summary
Functions
Resolve and run an RPC in the (already resolved) profile schema.
Resolve the routine an OPTIONS /rpc/<fn> request targets.
Functions
Resolve and run an RPC in the (already resolved) profile schema.
The Prefer header is parsed with the same reader the relation path uses: a
call plans as a CallReadPlan, and responsePreferences masks only the
mutation-only preferences, passing count/handling/timezone through for every
plan (Response.hs#L296). So an RPC echoes Preference-Applied: count=exact
exactly like GET /items does — even for count=planned, which has no effect
on a call — while return= is never echoed. The header goes on the request
conn before the routine runs, so every success shape (setof, scalar, octet,
void) carries it and an error path, which answers from the untouched conn in
Bier.Plugs.ActionController, does not.
@spec resolve_routine(Plug.Conn.t(), map(), String.t(), String.t()) :: {:ok, map()} | {:error, term()}
Resolve the routine an OPTIONS /rpc/<fn> request targets.
PostgREST's ActRoutineInfo runs the same callReadPlan resolution a read
invocation does (ApiRequest.getAction hands OPTIONS an InvRead method), so
the overload is picked from the query-string argument names and an
unresolvable signature is the usual PGRST202. Only the resolved routine is
returned: the info response needs nothing but its volatility.