diff --git a/docs/integrations/systemd.rst b/docs/integrations/systemd.rst index d0aba9288..4151e5814 100644 --- a/docs/integrations/systemd.rst +++ b/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`` diff --git a/docs/postgrest.dict b/docs/postgrest.dict index 30679bfca..496a83ae6 100644 --- a/docs/postgrest.dict +++ b/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 diff --git a/docs/references/api/aggregate_functions.rst b/docs/references/api/aggregate_functions.rst index d4576c6e7..8fe1168ce 100644 --- a/docs/references/api/aggregate_functions.rst +++ b/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 ==================== diff --git a/docs/references/api/preferences.rst b/docs/references/api/preferences.rst index 46a16012d..d1d6e425c 100644 --- a/docs/references/api/preferences.rst +++ b/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 `_. It accepts all timezones in `pg_timezone_names `_. +The ``timezone`` preference allows you to change the `PostgreSQL timezone `_. It accepts all time zones in `pg_timezone_names `_. .. code-block:: bash @@ -85,7 +85,7 @@ The ``timezone`` preference allows you to change the `PostgreSQL timezone `). +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 `). .. 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 `. +However, with ``handling=strict``, an invalid time zone preference will throw an :ref:`error `. .. code-block:: bash diff --git a/docs/references/api/resource_representation.rst b/docs/references/api/resource_representation.rst index dbeee41ed..ec4358421 100644 --- a/docs/references/api/resource_representation.rst +++ b/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 diff --git a/docs/references/configuration.rst b/docs/references/configuration.rst index 0be64d224..775bb2c06 100644 --- a/docs/references/configuration.rst +++ b/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: diff --git a/docs/references/errors.rst b/docs/references/errors.rst index f60010065..8419448d0 100644 --- a/docs/references/errors.rst +++ b/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