docs: Fix spelling mistakes

docs/integrations/systemd.rst

@@ -1,7 +1,7 @@
 systemd
 =======
 
-For Linux distributions that use **systemd** (Ubuntu, Debian, Archlinux) you can create a daemon in the following way.
+For Linux distributions that use **systemd** (Ubuntu, Debian, Arch Linux) you can create a daemon in the following way.
 
 First, create postgrest configuration in ``/etc/postgrest/config``
 

docs/postgrest.dict

@@ -1,8 +1,8 @@
 personal_ws-1.1 en 0 utf-8
 api
 API's
+APIs
 APISIX
-Archlinux
 aud
 Auth
 auth
@@ -147,6 +147,7 @@ spreaded
 Spreaded
 SQL
 sql
+SQLSTATE
 sr
 SSL
 stateful

docs/references/api/aggregate_functions.rst

@@ -82,7 +82,7 @@ This would return a row for each unique value in the ``order_date`` column, with
     }
   ]
 
-When ``count()`` is used with an associated column, its behaviour is slightly different: It will return the count of all values that are not ``NULL``. This is due to how PostgreSQL itself implements the ``count()`` function.
+When ``count()`` is used with an associated column, its behavior is slightly different: It will return the count of all values that are not ``NULL``. This is due to how PostgreSQL itself implements the ``count()`` function.
 
 Renaming and Casting
 ====================

docs/references/api/preferences.rst

@@ -63,7 +63,7 @@ The server ignores unrecognized or unfulfillable preferences by default. You can
 Timezone
 ========
 
-The ``timezone`` preference allows you to change the `PostgreSQL timezone <https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-TIMEZONE>`_. It accepts all timezones in `pg_timezone_names <https://www.postgresql.org/docs/current/view-pg-timezone-names.html>`_.
+The ``timezone`` preference allows you to change the `PostgreSQL timezone <https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-TIMEZONE>`_. It accepts all time zones in `pg_timezone_names <https://www.postgresql.org/docs/current/view-pg-timezone-names.html>`_.
 
 
 .. code-block:: bash
@@ -85,7 +85,7 @@ The ``timezone`` preference allows you to change the `PostgreSQL timezone <https
     {"t":"2023-10-18T09:37:59.611-07:00"}
   ]
 
-For an invalid timezone, PostgREST returns values with the default timezone (configured on ``postgresql.conf`` or as a setting on the :ref:`authenticator <roles>`).
+For an invalid time zone, PostgREST returns values with the default time zone (configured on ``postgresql.conf`` or as a setting on the :ref:`authenticator <roles>`).
 
 .. code-block:: bash
 
@@ -107,7 +107,7 @@ For an invalid timezone, PostgREST returns values with the default timezone (con
 
 Note that there's no ``Preference-Applied`` in the response.
 
-However, with ``handling=strict``, an invalid timezone preference will throw an :ref:`error <pgrst122>`.
+However, with ``handling=strict``, an invalid time zone preference will throw an :ref:`error <pgrst122>`.
 
 .. code-block:: bash
 

docs/references/api/resource_representation.rst

@@ -108,7 +108,7 @@ By default PostgREST returns all JSON null values. For example, requesting ``/pr
     { "id": 13, "name": "Y",        "client_id": null, "another_col": null }
   ]
 
-On large result sets, the unused keys with ``null`` values can waste bandwith unnecessarily. To remove them, specify ``nulls=stripped`` as a parameter of ``application/vnd.pgrst.array``:
+On large result sets, the unused keys with ``null`` values can waste bandwidth unnecessarily. To remove them, specify ``nulls=stripped`` as a parameter of ``application/vnd.pgrst.array``:
 
 .. code-block:: bash
 

docs/references/configuration.rst

@@ -176,7 +176,7 @@ app.settings.*
   **In-Database** `n/a`
   =============== =======================
 
-  Arbitrary settings that can be used to pass in secret keys directly as strings, or via OS environment variables. For instance: :code:`app.settings.jwt_secret = "$(MYAPP_JWT_SECRET)"` will take :code:`MYAPP_JWT_SECRET` from the environment and make it available to postgresql functions as :code:`current_setting('app.settings.jwt_secret')`.
+  Arbitrary settings that can be used to pass in secret keys directly as strings, or via OS environment variables. For instance: :code:`app.settings.jwt_secret = "$(MYAPP_JWT_SECRET)"` will take :code:`MYAPP_JWT_SECRET` from the environment and make it available to PostgreSQL functions as :code:`current_setting('app.settings.jwt_secret')`.
 
 .. _db-aggregates-enabled:
 

docs/references/errors.rst

@@ -392,7 +392,7 @@ Returns:
 Add HTTP Headers with RAISE
 ---------------------------
 
-For full control over headers and status you can raise a ``PGRST`` SQLSTATE error. You can achieve this by adding the ``code``, ``message``, ``detail`` and ``hint`` in the postgresql error message field as a JSON object. Here, the ``details`` and ``hint`` are optional. Similarly, the ``status`` and ``headers`` must be added to the SQL error detail field as a JSON object. For instance:
+For full control over headers and status you can raise a ``PGRST`` SQLSTATE error. You can achieve this by adding the ``code``, ``message``, ``detail`` and ``hint`` in the PostgreSQL error message field as a JSON object. Here, the ``details`` and ``hint`` are optional. Similarly, the ``status`` and ``headers`` must be added to the SQL error detail field as a JSON object. For instance:
 
 .. code-block:: sql