Stored Procedures

“A single resource can be the equivalent of a database stored procedure, with the power to abstract state changes over any number of storage items”Roy T. Fielding

Procedures can perform any operations allowed by PostgreSQL (read data, modify data, raise errors, and even DDL operations). Every stored procedure in the exposed schema and accessible by the active database role is executable under the /rpc prefix.

If they return table types, Stored Procedures can:


Why the /rpc prefix? PostgreSQL allows a table or view to have the same name as a function. The prefix allows us to avoid routes collisions.

Calling with POST

To supply arguments in an API call, include a JSON object in the request payload. Each key/value of the object will become an argument.

For instance, assume we have created this function in the database.

CREATE FUNCTION add_them(a integer, b integer)
RETURNS integer AS $$
 SELECT a + b;


Whenever you create or change a function you must refresh PostgREST’s schema cache. See the section Schema Cache Reloading.

The client can call it by posting an object like

POST /rpc/add_them HTTP/1.1

{ "a": 1, "b": 2 }


PostgreSQL converts identifier names to lowercase unless you quote them like:

CREATE FUNCTION "someFunc"("someParam" text) ...

Calling with GET

If the function doesn’t modify the database, it will also run under the GET method (see Access Mode).

GET /rpc/add_them?a=1&b=2 HTTP/1.1

The function parameter names match the JSON object keys in the POST case, for the GET case they match the query parameters ?a=1&b=2.

Functions with a single JSON parameter

You can also call a function that takes a single parameter of type JSON by sending the header Prefer: params=single-object with your request. That way the JSON request body will be used as the single argument.

CREATE FUNCTION mult_them(param json) RETURNS int AS $$
  SELECT (param->>'x')::int * (param->>'y')::int
POST /rpc/mult_them HTTP/1.1
Prefer: params=single-object

{ "x": 4, "y": 2 }

Functions with a single unnamed parameter

You can make a POST request to a function with a single unnamed parameter to send raw json/jsonb, bytea, text or xml data.

To send raw JSON, the function must have a single unnamed json or jsonb parameter and the header Content-Type: application/json must be included in the request.

CREATE FUNCTION mult_them(json) RETURNS int AS $$
  SELECT ($1->>'x')::int * ($1->>'y')::int
POST /rpc/mult_them HTTP/1.1
Content-Type: application/json

{ "x": 4, "y": 2 }


If an overloaded function has a single json or jsonb unnamed parameter, PostgREST will call this function as a fallback provided that no other overloaded function is found with the parameters sent in the POST request.

To send raw XML, the parameter type must be xml and the header Content-Type: text/xml must be included in the request.

To send raw binary, the parameter type must be bytea and the header Content-Type: application/octet-stream must be included in the request.

CREATE TABLE files(blob bytea);

CREATE FUNCTION upload_binary(bytea) RETURNS void AS $$
  INSERT INTO files(blob) VALUES ($1);
POST /rpc/upload_binary HTTP/1.1
Content-Type: application/octet-stream

HTTP/1.1 200 OK

[ ... ]

To send raw text, the parameter type must be text and the header Content-Type: text/plain must be included in the request.

Functions with array parameters

You can call a function that takes an array parameter:

create function plus_one(arr int[]) returns int[] as $$
   SELECT array_agg(n + 1) FROM unnest($1) AS n;
$$ language sql;
POST /rpc/plus_one HTTP/1.1
Content-Type: application/json

{"arr": [1,2,3,4]}

For calling the function with GET, you can pass the array as an array literal, as in {1,2,3,4}. Note that the curly brackets have to be urlencoded({ is %7B and } is %7D).

GET /rpc/plus_one?arr=%7B1,2,3,4%7D' HTTP/1.1


For versions prior to PostgreSQL 10, to pass a PostgreSQL native array on a POST payload, you need to quote it and use an array literal:

POST /rpc/plus_one HTTP/1.1

{ "arr": "{1,2,3,4}" }

In these versions we recommend using function parameters of type JSON to accept arrays from the client.

Variadic functions

You can call a variadic function by passing a JSON array in a POST request:

create function plus_one(variadic v int[]) returns int[] as $$
   SELECT array_agg(n + 1) FROM unnest($1) AS n;
$$ language sql;
POST /rpc/plus_one HTTP/1.1
Content-Type: application/json

{"v": [1,2,3,4]}

In a GET request, you can repeat the same parameter name:

GET /rpc/plus_one?v=1&v=2&v=3&v=4 HTTP/1.1

Repeating also works in POST requests with Content-Type: application/x-www-form-urlencoded:

POST /rpc/plus_one HTTP/1.1
Content-Type: application/x-www-form-urlencoded


Table-Valued Functions

A function that returns a table type can be filtered using the same filters as tables and views. They can also use Resource Embedding.

CREATE FUNCTION best_films_2017() RETURNS SETOF films ..
GET /rpc/best_films_2017?select=title,director:directors(*) HTTP/1.1
GET /rpc/best_films_2017?rating=gt.8&order=title.desc HTTP/1.1

Function Inlining

A function that follows the rules for inlining will also inline filters, order and limits.

For example, for the following function:

create function getallprojects() returns setof projects
language sql stable
as $$
  select * from projects;

Let’s get its Execution plan when calling it with filters applied:

GET /rpc/getallprojects?id=eq.1 HTTP/1.1
Accept: application/vnd.pgrst.plan
Aggregate  (cost=8.18..8.20 rows=1 width=112)
  ->  Index Scan using projects_pkey on projects  (cost=0.15..8.17 rows=1 width=40)
        Index Cond: (id = 1)

Notice there’s no “Function Scan” node in the plan, which tells us it has been inlined.

Scalar functions

PostgREST will detect if the function is scalar or table-valued and will shape the response format accordingly:

GET /rpc/add_them?a=1&b=2 HTTP/1.1
GET /rpc/best_films_2017 HTTP/1.1
  { "title": "Okja", "rating": 7.4},
  { "title": "Call me by your name", "rating": 8},
  { "title": "Blade Runner 2049", "rating": 8.1}

To manually choose a return format such as binary, see Media Type Handlers.

Untyped functions

Functions that return record or SETOF record are supported:

create function projects_setof_record() returns setof record as $$
  select * from projects;
$$ language sql;
GET /rpc/projects_setof_record HTTP/1.1
[{"id":1,"name":"Windows 7","client_id":1},
 {"id":2,"name":"Windows 10","client_id":1},

However note that they will fail when trying to use Vertical Filtering and Horizontal Filtering on them.

So while they can be used for quick tests, it’s recommended to always choose a strict return type for the function.

Overloaded functions

You can call overloaded functions with different number of arguments.

CREATE FUNCTION rental_duration(customer_id integer) ..

CREATE FUNCTION rental_duration(customer_id integer, from_date date) ..
GET /rpc/rental_duration?customer_id=232 HTTP/1.1
GET /rpc/rental_duration?customer_id=232&from_date=2018-07-01 HTTP/1.1


Overloaded functions with the same argument names but different types are not supported.