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/_diagrams/db.tex

@@ -52,7 +52,7 @@
 % Text Node
 \draw (414,127) node [anchor=north west][inner sep=0.75pt]   [align=left] {tables};
 % Text Node
-\draw (272,203) node [anchor=north west][inner sep=0.75pt]  [color={rgb, 255:red, 0; green, 0; blue, 0 }  ,opacity=1 ] [align=center] { \\ views \\ + \\ \ \ stored procedures};
+\draw (300,203) node [anchor=north west][inner sep=0.75pt]  [color={rgb, 255:red, 0; green, 0; blue, 0 }  ,opacity=1 ] [align=center] { \\ views \\ + \\ \ \ functions};
 
 % Text Node
 \draw (322,178) node [anchor=north west][inner sep=0.75pt]  [color={rgb, 255:red, 255; green, 255; blue, 255 }  ,opacity=1 ] [align=left] {\large\textbf{api}};

docs/ecosystem.rst

@@ -9,7 +9,7 @@ Community Tutorials
 * `PostgREST + Auth0: Create REST API in mintutes, and add social login using Auth0 <https://samkhawase.com/blog/postgrest/>`_ - A step-by-step tutorial to show how to dockerize and integrate Auth0 to PostgREST service.
 
 * `PostgREST + PostGIS API tutorial in 5 minutes <https://gis-ops.com/postgrest-postgis-api-tutorial-geospatial-api-in-5-minutes/>`_ -
-  In this tutorial, GIS • OPS shows how to perform PostGIS calculations through PostgREST :ref:`s_procs` interface.
+  In this tutorial, GIS • OPS shows how to perform PostGIS calculations through PostgREST :ref:`functions` interface.
 
 * `"CodeLess" backend using postgres, postgrest and oauth2 authentication with keycloak <https://www.mathieupassenaud.fr/codeless_backend/>`_ -
   A step-by-step tutorial for using PostgREST with KeyCloak(hosted on a managed service).
@@ -60,7 +60,7 @@ DevOps
 External Notification
 ---------------------
 
-These are PostgreSQL bridges that propagate LISTEN/NOTIFY to external queues for further processing. This allows stored procedures to initiate actions outside the database such as sending emails.
+These are PostgreSQL bridges that propagate LISTEN/NOTIFY to external queues for further processing. This allows functions to initiate actions outside the database such as sending emails.
 
 * `pg-notify-webhook <https://github.com/vbalasu/pg-notify-webhook>`_ - trigger webhooks from PostgreSQL's LISTEN/NOTIFY
 * `pgsql-listen-exchange <https://github.com/gmr/pgsql-listen-exchange>`_ - RabbitMQ

docs/explanations/db_authz.rst

@@ -156,7 +156,7 @@ You can also grant execute on all functions in a schema to a higher privileged r
 Security definer
 ----------------
 
-A function is executed with the privileges of the user who calls it. This means that the user has to have all permissions to do the operations the procedure performs.
+A function is executed with the privileges of the user who calls it. This means that the user has to have all permissions to do the operations the function performs.
 If the function accesses private database objects, your :ref:`API roles <roles>` won't be able to successfully execute the function.
 
 Another option is to define the function with the :code:`SECURITY DEFINER` option. Then only one permission check will take place, the permission to call the function, and the operations in the function will have the authority of the user who owns the function itself.
@@ -180,7 +180,7 @@ Note the ``SECURITY DEFINER`` keywords at the end of the function. See `PostgreS
 Views
 =====
 
-Views are invoked with the privileges of the view owner, much like stored procedures with the ``SECURITY DEFINER`` option. When created by a SUPERUSER role, all `row-level security <https://www.postgresql.org/docs/current/ddl-rowsecurity.html>`_ policies will be bypassed.
+Views are invoked with the privileges of the view owner, much like functions with the ``SECURITY DEFINER`` option. When created by a SUPERUSER role, all `row-level security <https://www.postgresql.org/docs/current/ddl-rowsecurity.html>`_ policies will be bypassed.
 
 If you're on PostgreSQL >= 15, this behavior can be changed by specifying the ``security_invoker`` option.
 

docs/explanations/nginx.rst

@@ -55,7 +55,7 @@ Nginx supports "leaky bucket" rate limiting (see `official docs <https://nginx.o
 
 This creates a shared memory zone called "login" to store a log of IP addresses that access the rate limited urls. The space reserved, 10 MB (:code:`10m`) will give us enough space to store a history of 160k requests. We have chosen to allow only allow one request per second (:code:`1r/s`).
 
-Next we apply the zone to certain routes, like a hypothetical stored procedure called :code:`login`.
+Next we apply the zone to certain routes, like a hypothetical function called :code:`login`.
 
 .. code-block:: nginx
 

docs/explanations/schema_isolation.rst

@@ -7,9 +7,9 @@
 Schema Isolation
 ================
 
-A PostgREST instance exposes all the tables, views, and stored procedures of a single `PostgreSQL schema <https://www.postgresql.org/docs/current/ddl-schemas.html>`_ (a namespace of database objects). This means private data or implementation details can go inside different private schemas and be invisible to HTTP clients.
+A PostgREST instance exposes all the tables, views, and functions of a single `PostgreSQL schema <https://www.postgresql.org/docs/current/ddl-schemas.html>`_ (a namespace of database objects). This means private data or implementation details can go inside different private schemas and be invisible to HTTP clients.
 
-It is recommended that you don't expose tables on your API schema. Instead expose views and stored procedures which insulate the internal details from the outside world.
+It is recommended that you don't expose tables on your API schema. Instead expose views and functions which insulate the internal details from the outside world.
 This allows you to change the internals of your schema and maintain backwards compatibility. It also keeps your code easier to refactor, and provides a natural way to do API versioning.
 
 .. image:: ../_static/db.png

docs/how-tos/create-soap-endpoint.rst

@@ -191,7 +191,7 @@ References
 
 For more information concerning PostgREST, cf.
 
-- :ref:`s_proc_single_unnamed`
+- :ref:`function_single_unnamed`
 - :ref:`custom_media`. See :ref:`any_handler`, if you need to support an ``application/soap+xml`` media type or if you want to respond with XML without sending a media type.
 - :ref:`Nginx reverse proxy <nginx>`
 

docs/how-tos/sql-user-management.rst

@@ -115,7 +115,7 @@ JWT from SQL
 
 You can create JWT tokens in SQL using the `pgjwt extension <https://github.com/michelp/pgjwt>`_. It's simple and requires only pgcrypto. If you're on an environment like Amazon RDS which doesn't support installing new extensions, you can still manually run the `SQL inside pgjwt <https://github.com/michelp/pgjwt/blob/master/pgjwt--0.1.1.sql>`_ (you'll need to replace ``@extschema@`` with another schema or just delete it) which creates the functions you will need.
 
-Next write a stored procedure that returns the token. The one below returns a token with a hard-coded role, which expires five minutes after it was issued. Note this function has a hard-coded secret as well.
+Next write a function that returns the token. The one below returns a token with a hard-coded role, which expires five minutes after it was issued. Note this function has a hard-coded secret as well.
 
 .. code-block:: postgres
 
@@ -134,7 +134,7 @@ PostgREST exposes this function to clients via a POST request to ``/rpc/jwt_test
 
 .. note::
 
-  To avoid hard-coding the secret in stored procedures, save it as a property of the database.
+  To avoid hard-coding the secret in functions, save it as a property of the database.
 
   .. code-block:: postgres
 

docs/references/api.rst

@@ -3,14 +3,14 @@
 API
 ###
 
-PostgREST exposes three database objects of a schema as resources: tables, views and stored procedures.
+PostgREST exposes three database objects of a schema as resources: tables, views and functions.
 
 .. toctree::
    :glob:
    :maxdepth: 1
 
    api/tables_views.rst
-   api/stored_procedures.rst
+   api/functions.rst
    api/schemas.rst
    api/computed_fields.rst
    api/domain_representations.rst
@@ -55,15 +55,15 @@ PostgREST exposes three database objects of a schema as resources: tables, views
       '#put': 'api/tables_views.html#put',
       '#deletions': 'api/tables_views.html#delete',
       '#limited-updates-deletions': 'api/tables_views.html#limited-update-delete',
-      // Stored procedures
+      // Functions
-      '#stored-procedures': 'api/stored_procedures.html#stored-procedures',
+      '#stored-procedures': 'api/functions.html#functions',
-      '#calling-functions-with-a-single-json-parameter': 'api/stored_procedures.html#functions-with-a-single-json-parameter',
+      '#calling-functions-with-a-single-json-parameter': 'api/functions.html#functions-with-a-single-json-parameter',
-      '#calling-functions-with-a-single-unnamed-parameter': 'api/stored_procedures.html#functions-with-a-single-unnamed-parameter',
+      '#calling-functions-with-a-single-unnamed-parameter': 'api/functions.html#functions-with-a-single-unnamed-parameter',
-      '#calling-functions-with-array-parameters': 'api/stored_procedures.html#functions-with-array-parameters',
+      '#calling-functions-with-array-parameters': 'api/functions.html#functions-with-array-parameters',
-      '#calling-variadic-functions': 'api/stored_procedures.html#variadic-functions',
+      '#calling-variadic-functions': 'api/functions.html#variadic-functions',
-      '#scalar-functions': 'api/stored_procedures.html#scalar-functions',
+      '#scalar-functions': 'api/functions.html#scalar-functions',
-      '#function-filters': 'api/stored_procedures.html#table-valued-functions',
+      '#function-filters': 'api/functions.html#table-valued-functions',
-      '#overloaded-functions': 'api/stored_procedures.html#overloaded-functions',
+      '#overloaded-functions': 'api/functions.html#overloaded-functions',
       // Schemas
       '#switching-schemas': 'api/schemas.html',
       // Resource Embedding
@@ -79,7 +79,7 @@ PostgREST exposes three database objects of a schema as resources: tables, views
       '#embedding-partitioned-tables': 'api/resource_embedding.html#embedding-partitioned-tables',
       '#embedding-views': 'api/resource_embedding.html#embedding-views',
       '#embedding-chains-of-views': 'api/resource_embedding.html#embedding-chains-of-views',
-      '#embedding-on-stored-procedures': 'api/resource_embedding.html#embedding-on-stored-procedures',
+      '#embedding-on-stored-procedures': 'api/resource_embedding.html#embedding-on-functions',
       '#embedding-after-insertions-updates-deletions': 'api/resource_embedding.html#embedding-after-insertions-updates-deletions',
       '#embedding-disambiguation': 'api/resource_embedding.html#embedding-disambiguation',
       '#target-disambiguation': 'api/resource_embedding.html#target-disambiguation',

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`.

docs/references/auth.rst

@@ -177,7 +177,7 @@ PostgREST uses JWT mainly for authentication and authorization purposes and enco
 Custom Validation
 -----------------
 
-PostgREST does not enforce any extra constraints besides JWT validation. An example of an extra constraint would be to immediately revoke access for a certain user. Using :ref:`db-pre-request` you can specify a stored procedure to call immediately after :ref:`user_impersonation` and before the main query itself runs.
+PostgREST does not enforce any extra constraints besides JWT validation. An example of an extra constraint would be to immediately revoke access for a certain user. Using :ref:`db-pre-request` you can specify a function to call immediately after :ref:`user_impersonation` and before the main query itself runs.
 
 .. code:: ini
 

docs/references/configuration.rst

@@ -292,7 +292,7 @@ db-extra-search-path
   **In-Database** pgrst.db_extra_search_path
   =============== ==========================
 
-  Extra schemas to add to the `search_path <https://www.postgresql.org/docs/current/ddl-schemas.html#DDL-SCHEMAS-PATH>`_ of every request. These schemas tables, views and stored procedures **don't get API endpoints**, they can only be referred from the database objects inside your :ref:`db-schemas`.
+  Extra schemas to add to the `search_path <https://www.postgresql.org/docs/current/ddl-schemas.html#DDL-SCHEMAS-PATH>`_ of every request. These schemas tables, views and functions **don't get API endpoints**, they can only be referred from the database objects inside your :ref:`db-schemas`.
 
   This parameter was meant to make it easier to use **PostgreSQL extensions** (like PostGIS) that are outside of the :ref:`db-schemas`.
 
@@ -313,7 +313,7 @@ db-max-rows
 
   *For backwards compatibility, this config parameter is also available without prefix as "max-rows".*
 
-  A hard limit to the number of rows PostgREST will fetch from a view, table, or stored procedure. Limits payload size for accidental or malicious requests.
+  A hard limit to the number of rows PostgREST will fetch from a view, table, or function. Limits payload size for accidental or malicious requests.
 
 .. _db-plan-enabled:
 
@@ -424,7 +424,7 @@ db-pre-request
 
   *For backwards compatibility, this config parameter is also available without prefix as "pre-request".*
 
-  A schema-qualified stored procedure name to call right after the :ref:`tx_settings` are set. See :ref:`pre-request`.
+  A schema-qualified function name to call right after the :ref:`tx_settings` are set. See :ref:`pre-request`.
 
 .. _db-prepared-statements:
 

docs/references/connection_pool.rst

@@ -60,7 +60,7 @@ If the request reaches the timeout, it will be aborted with the following respon
 
     - Reduce write requests. Do :ref:`bulk_insert` (or :ref:`upsert`) instead of inserting rows one by one.
     - Reduce read requests. Use :ref:`resource_embedding`. Combine unrelated data into a single request using custom database views or functions.
-    - Use :ref:`s_procs` for combining read and write logic into a single request.
+    - Use :ref:`functions` for combining read and write logic into a single request.
 
   - Increase the :ref:`db-pool` size.
 

docs/references/errors.rst

@@ -173,7 +173,7 @@ Related to the HTTP request elements.
 |               |             | See :ref:`h_filter`, :ref:`operators` and :ref:`ordering`.  |
 | PGRST100      |             |                                                             |
 +---------------+-------------+-------------------------------------------------------------+
-| .. _pgrst101: | 405         | For :ref:`functions <s_procs>`, only ``GET`` and ``POST``   |
+| .. _pgrst101: | 405         | For :ref:`functions <functions>`, only ``GET`` and ``POST`` |
 |               |             | verbs are allowed. Any other verb will throw this error.    |
 | PGRST101      |             |                                                             |
 +---------------+-------------+-------------------------------------------------------------+
@@ -337,7 +337,7 @@ You can customize the errors by using the `RAISE statement <https://www.postgres
 RAISE errors with HTTP Status Codes
 -----------------------------------
 
-Custom status codes can be done by raising SQL exceptions inside :ref:`functions <s_procs>`. For instance, here's a saucy function that always responds with an error:
+Custom status codes can be done by raising SQL exceptions inside :ref:`functions <functions>`. For instance, here's a saucy function that always responds with an error:
 
 .. code-block:: postgres
 

docs/references/schema_cache.rst

@@ -10,7 +10,7 @@ Some PostgREST features need metadata from the database schema. Getting this met
 +============================================+===============================================================================+
 | :ref:`resource_embedding`                  | Foreign key constraints                                                       |
 +--------------------------------------------+-------------------------------------------------------------------------------+
-| :ref:`Stored Functions <s_procs>`          | Function signature (parameters, return type, volatility and                   |
+| :ref:`Functions <functions>`               | Function signature (parameters, return type, volatility and                   |
 |                                            | `overloading <https://www.postgresql.org/docs/current/xfunc-overload.html>`_) |
 +--------------------------------------------+-------------------------------------------------------------------------------+
 | :ref:`Upserts <upsert>`                    | Primary keys                                                                  |

docs/references/transactions.rst

@@ -58,7 +58,7 @@ The access mode on :ref:`tables_views` is determined by the HTTP method.
 Access Mode on Functions
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-:ref:`s_procs` additionally depend on the function `volatility <https://www.postgresql.org/docs/current/xfunc-volatility.html>`_.
+:ref:`functions` additionally depend on the function `volatility <https://www.postgresql.org/docs/current/xfunc-volatility.html>`_.
 
 .. list-table::
    :header-rows: 2
@@ -299,7 +299,7 @@ the impersonated and connection role settings.
   LANGUAGE SQL
   SET statement_timeout TO '4s';
 
-When calling the above function (see :ref:`s_procs`), the statement timeout will be 4 seconds.
+When calling the above function (see :ref:`functions`), the statement timeout will be 4 seconds.
 
 .. note::
 
@@ -310,7 +310,7 @@ When calling the above function (see :ref:`s_procs`), the statement timeout will
 Main query
 ----------
 
-The main query is generated by requesting :ref:`tables_views` or :ref:`s_procs`. All generated queries use prepared statements (:ref:`db-prepared-statements`).
+The main query is generated by requesting :ref:`tables_views` or :ref:`functions`. All generated queries use prepared statements (:ref:`db-prepared-statements`).
 
 .. _tx_end:
 

docs/tutorials/tut0.rst

@@ -11,7 +11,7 @@ PostgREST is a standalone web server which turns a PostgreSQL database into a RE
 
 .. image:: ../_static/tuts/tut0-request-flow.png
 
-To make an API we'll simply be building a database. All the endpoints and permissions come from database objects like tables, views, roles, and stored procedures. These tutorials will cover a number of common scenarios and how to model them in the database.
+To make an API we'll simply be building a database. All the endpoints and permissions come from database objects like tables, views, roles, and functions. These tutorials will cover a number of common scenarios and how to model them in the database.
 
 By the end of this tutorial you'll have a working database, PostgREST server, and a simple single-user todo list API.
 

docs/tutorials/tut1.rst

@@ -202,7 +202,7 @@ Save it to an environment variable:
 
   export WAYWARD_TOKEN="<paste new token>"
 
-PostgREST allows us to specify a stored procedure to run during attempted authentication. The function can do whatever it likes, including raising an exception to terminate the request.
+PostgREST allows us to specify a function to run during attempted authentication. The function can do whatever it likes, including raising an exception to terminate the request.
 
 First make a new schema and add the function: