docs: Rename Stored Procedures to Functions consistently

This avoids confusing our RPCs with actual CREATE PROCEDURE, which we don't
support.

References https://github.com/PostgREST/postgrest-docs/issues/147

docs/references/api/computed_fields.rst

@@ -66,7 +66,7 @@ Ordering on Computed Fields
 
 .. important::
 
-  Computed fields must be created in the :ref:`exposed schema <db-schemas>` or in a schema in the :ref:`extra search path <db-extra-search-path>` to be used in this way. When placing the computed field in the :ref:`exposed schema <db-schemas>` you can use an **unnamed** parameter, as in the example above, to prevent it from being exposed as an :ref:`RPC <s_procs>` under ``/rpc``.
+  Computed fields must be created in the :ref:`exposed schema <db-schemas>` or in a schema in the :ref:`extra search path <db-extra-search-path>` to be used in this way. When placing the computed field in the :ref:`exposed schema <db-schemas>` you can use an **unnamed** parameter, as in the example above, to prevent it from being exposed as an :ref:`RPC <functions>` under ``/rpc``.
 
 .. note::
 

docs/references/api/functions.rst

@@ -1,16 +1,16 @@
-.. _s_procs:
+.. _functions:
 
-Stored Procedures
-=================
+Functions as RPC
+================
 
-*"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 <http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-743>`_
+*"A single resource can be the equivalent of a database function, with the power to abstract state changes over any number of storage items"* -- `Roy T. Fielding <http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-743>`_
 
-Procedures can perform any operations allowed by PostgreSQL (read data, modify data, :ref:`raise errors <raise_error>`, and even DDL operations). Every stored procedure in the :ref:`exposed schema <schemas>` and accessible by the :ref:`active database role <roles>` is executable under the :code:`/rpc` prefix.
+Function can perform any operations allowed by PostgreSQL (read data, modify data, :ref:`raise errors <raise_error>`, and even DDL operations). Every function in the :ref:`exposed schema <schemas>` and accessible by the :ref:`active database role <roles>` is executable under the :code:`/rpc` prefix.
 
-If they return table types, Stored Procedures can:
+If they return table types, functions can:
 
 - Use all the same :ref:`read filters as Tables and Views <read>` (horizontal/vertical filtering, counts, limits, etc.).
-- Use :ref:`Resource Embedding <s_proc_embed>`, if the returned table type has relationships to other tables.
+- Use :ref:`Resource Embedding <function_embed>`, if the returned table type has relationships to other tables.
 
 .. note::
 
@@ -65,7 +65,7 @@ If the function doesn't modify the database, it will also run under the GET meth
 
 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``.
 
-.. _s_proc_single_json:
+.. _function_single_json:
 
 Functions with a single unnamed JSON parameter
 ----------------------------------------------
@@ -97,7 +97,7 @@ For this the ``Content-Type: application/json`` header must be included in the r
 
  Sending the JSON request body as a single argument is also possible with :ref:`Prefer: params=single-object <prefer_params>` but this method is **deprecated**.
 
-.. _s_proc_single_unnamed:
+.. _function_single_unnamed:
 
 Functions with a single unnamed parameter
 -----------------------------------------
@@ -130,7 +130,7 @@ To send raw binary, the parameter type must be ``bytea`` and the header ``Conten
 
 To send raw text, the parameter type must be ``text`` and the header ``Content-Type: text/plain`` must be included in the request.
 
-.. _s_procs_array:
+.. _functions_array:
 
 Functions with array parameters
 -------------------------------
@@ -172,7 +172,7 @@ as in ``{1,2,3,4}``. Note that the curly brackets have to be urlencoded(``{`` is
 
    In these versions we recommend using function parameters of type JSON to accept arrays from the client.
 
-.. _s_procs_variadic:
+.. _functions_variadic:
 
 Variadic functions
 ------------------
@@ -214,7 +214,7 @@ Repeating also works in POST requests with ``Content-Type: application/x-www-for
 Table-Valued Functions
 ----------------------
 
-A function that returns a table type can be filtered using the same filters as :ref:`tables and views <tables_views>`. They can also use :ref:`Resource Embedding <s_proc_embed>`.
+A function that returns a table type can be filtered using the same filters as :ref:`tables and views <tables_views>`. They can also use :ref:`Resource Embedding <function_embed>`.
 
 .. code-block:: postgres
 

docs/references/api/media_type_handlers.rst

@@ -11,7 +11,7 @@ Media types are expressed as type aliases using `domains <https://www.postgresql
 
    CREATE DOMAIN "application/json" AS json;
 
-Using these domains, :ref:`functions <s_procs>` can become handlers and `user-defined aggregates <https://www.postgresql.org/docs/current/xaggr.html>`_ can serve as handlers for :ref:`tables_views` and :ref:`table_functions`.
+Using these domains, :ref:`functions <functions>` can become handlers and `user-defined aggregates <https://www.postgresql.org/docs/current/xaggr.html>`_ can serve as handlers for :ref:`tables_views` and :ref:`table_functions`.
 
 .. important::
 

docs/references/api/preferences.rst

@@ -232,9 +232,9 @@ Single JSON object as Function Parameter
 
 .. warning::
 
-  Using this preference is **deprecated** in favor of :ref:`s_proc_single_json`.
+  Using this preference is **deprecated** in favor of :ref:`function_single_json`.
 
-:code:`Prefer: params=single-object` allows sending the JSON request body as the single argument of a :ref:`function <s_procs>`.
+:code:`Prefer: params=single-object` allows sending the JSON request body as the single argument of a :ref:`function <functions>`.
 
 .. code-block:: postgres
 

docs/references/api/resource_embedding.rst

@@ -747,12 +747,12 @@ Foreign Key Joins on Chains of Views
 
 Views can also depend on other views, which in turn depend on the actual base table. For PostgREST to pick up those chains recursively to any depth, all the views must be in the search path, so either in the exposed schema (:ref:`db-schemas`) or in one of the schemas set in :ref:`db-extra-search-path`. This does not apply to the base table, which could be in a private schema as well. See :ref:`schema_isolation` for more details.
 
-.. _s_proc_embed:
+.. _function_embed:
 
 Foreign Key Joins on Table-Valued Functions
 ===========================================
 
-If you have a :ref:`Stored Procedure <s_procs>` that returns a table type, you can do a Foreign Key join on the result.
+If you have a :ref:`Function <functions>` that returns a table type, you can do a Foreign Key join on the result.
 
 Here's a sample function (notice the ``RETURNS SETOF films``).
 

docs/references/api/resource_representation.rst

@@ -23,7 +23,7 @@ Builtin Media Type Handlers
 
 Builtin handlers are offered for common standard media types.
 
-* ``text/csv`` and ``application/json``, for all API endpoints. See :ref:`tables_views` and :ref:`s_procs`.
+* ``text/csv`` and ``application/json``, for all API endpoints. See :ref:`tables_views` and :ref:`functions`.
 * ``application/openapi+json``, for the root endpoint. See :ref:`open-api`.
 * ``application/geo+json``, see :ref:`ww_postgis`.
 * ``*/*``, resolves to ``application/json`` for API endpoints and to ``application/openapi+json`` for the root endpoint.
@@ -136,12 +136,12 @@ The server handles the following request body media types:
 * ``application/x-www-form-urlencoded``
 * ``text/csv``
 
-For :ref:`tables_views` this works on ``POST``, ``PATCH`` and ``PUT`` methods. For :ref:`s_procs`, it works on ``POST`` methods.
+For :ref:`tables_views` this works on ``POST``, ``PATCH`` and ``PUT`` methods. For :ref:`functions`, it works on ``POST`` methods.
 
-For stored procedures there are three additional types:
+For functions there are three additional types:
 
 * ``application/octet-stream``
 * ``text/plain``
 * ``text/xml``
 
-See :ref:`s_proc_single_unnamed`.
+See :ref:`function_single_unnamed`.

docs/references/api/schemas.rst

@@ -59,7 +59,7 @@ For POST, PATCH, PUT and DELETE, select the schema with ``Content-Profile``.
     -H "Content-Profile: tenant2" \
     -d '{...}'
 
-You can also select the schema for :ref:`s_procs` and :ref:`open-api`.
+You can also select the schema for :ref:`functions` and :ref:`open-api`.
 
 Restricted schemas
 ~~~~~~~~~~~~~~~~~~

docs/references/api/tables_views.rst

@@ -86,7 +86,7 @@ all           :code:`ALL`               comparison matches all the values in the
 any           :code:`ANY`               comparison matches any value in the list, see :ref:`modifiers`
 ============  ========================  ==================================================================================
 
-For more complicated filters you will have to create a new view in the database, or use a stored procedure. For instance, here's a view to show "today's stories" including possibly older pinned stories:
+For more complicated filters you will have to create a new view in the database, or use a function. For instance, here's a view to show "today's stories" including possibly older pinned stories:
 
 .. code-block:: postgres
 
@@ -443,7 +443,7 @@ URL encoded payloads can be posted with ``Content-Type: application/x-www-form-u
 
   It's recommended that you `use triggers instead of rules <https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_rules>`_.
   Insertion on views with complex `rules <https://www.postgresql.org/docs/current/sql-createrule.html>`_ might not work out of the box with PostgREST due to its usage of CTEs.
-  If you want to keep using rules, a workaround is to wrap the view insertion in a stored procedure and call it through the :ref:`s_procs` interface.
+  If you want to keep using rules, a workaround is to wrap the view insertion in a function and call it through the :ref:`functions` interface.
   For more details, see this `github issue <https://github.com/PostgREST/postgrest/issues/1283>`_.
 
 .. _bulk_insert:

docs/references/api/url_grammar.rst

@@ -12,7 +12,7 @@ URL Grammar
 Custom Queries
 --------------
 
-The PostgREST URL grammar limits the kinds of queries clients can perform. It prevents arbitrary, potentially poorly constructed and slow client queries. It's good for quality of service, but means database administrators must create custom views and stored procedures to provide richer endpoints. The most common causes for custom endpoints are
+The PostgREST URL grammar limits the kinds of queries clients can perform. It prevents arbitrary, potentially poorly constructed and slow client queries. It's good for quality of service, but means database administrators must create custom views and functions to provide richer endpoints. The most common causes for custom endpoints are
 
 * Table unions
 * More complicated joins than those provided by :ref:`resource_embedding`.