| outline |
|
||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| title | BODY_PARAMETER_NAME Annotation | ||||||||||||||||||||||||||||
| titleTemplate | NpgsqlRest | ||||||||||||||||||||||||||||
| description | Specify which PostgreSQL function parameter receives the raw HTTP request body. Handle JSON payloads in SQL functions. | ||||||||||||||||||||||||||||
| head |
|
::: info Also known as
body_param_name (with or without @ prefix)
:::
Specify which parameter receives the raw request body.
@body_parameter_name <param-name>
create function process_payload(_metadata json, _payload text)
returns json
language sql
begin atomic;
...;
end;
comment on function process_payload(json, text) is
'HTTP POST
@body_parameter_name _payload';Equivalent as a SQL file endpoint (sql/process-payload.sql):
/*
HTTP POST
@body_parameter_name payload
@param $1 metadata json
@param $2 payload text
*/
select process_payload($1, $2);create function handle_webhook(_body json)
returns void
language sql
begin atomic;
...;
end;
comment on function handle_webhook(json) is
'HTTP POST
@body_parameter_name _body';- Directs the raw request body to the specified parameter
- Useful when you need access to the complete body content
- Parameter type should match expected content (text, json, bytea)
The parameter name is matched case-insensitively and accepts any of the parameter's names:
- the converted (API) name — e.g.
responseBody(camelCase), - the actual SQL name — e.g.
_response_body, - for a field expanded out of an HTTP Custom Type composite parameter, the expanded signature name (
_response_body) and the base composite name (_response, shared by all expanded fields — resolves to the first one).
::: tip New in 3.18.2 Before 3.18.2 the value was force-lowercased and compared case-sensitively, so the camelCase converted name never matched, and the expanded signature name of an HTTP Custom Type field matched nothing at all. From 3.18.2 the same matching rule is applied consistently by request handling and every code generator (TypeScript client, HTTP file, OpenAPI), so they no longer disagree about which parameter carries the body. :::
A common use is forwarding a large field — such as an HTTP Custom Type's responseBody — into a @proxy upstream request body instead of the query string (where an oversized value would be rejected, see MaxForwardedQueryParamLength). Target the field by its converted name (responseBody), its expanded signature name (_response_body), or the composite base (_response), and use a body-carrying method:
comment on function scrape_and_forward(...) is 'HTTP POST
@proxy https://upstream.example.com/ingest
@body_parameter_name responseBody';The remaining small fields still travel on the proxy query string.
- NpgsqlRest Options configuration - Configure default body parameter
- Comment Annotations Guide - How annotations work
- Configuration Guide - How configuration works
- REQUEST_PARAM_TYPE - Control parameter source
- HTTP_TYPE - HTTP Custom Type whose expanded fields can be targeted as the body
- PROXY - Forward the body field into an upstream request body