chore(deps): update nixpkgs to 25.05

docs/ecosystem.rst

@@ -34,7 +34,7 @@ Templates
 Example Apps
 ------------
 
-* `archtika <https://github.com/thiloho/archtika>`_ - self‑hosted CMS
+* `archtika <https://github.com/thiloho/archtika>`_ - self-hosted CMS
 * `delibrium-postgrest <https://gitlab.com/delibrium/delibrium-postgrest/>`_ - example school API and front-end in Vue.js
 * `ETH-transactions-storage <https://github.com/Adamant-im/ETH-transactions-storage>`_ - indexer for Ethereum to get transaction list by ETH address
 * `general <https://github.com/PierreRochard/general>`_ - example auth back-end

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

@@ -3,7 +3,7 @@
 SQL User Management
 ===================
 
-As mentioned on :ref:`jwt_generation`, an external service can provide user management and coordinate with the PostgREST server using JWT. It’s also possible to support logins entirely through SQL. It’s a fair bit of work, so get ready.
+As mentioned on :ref:`jwt_generation`, an external service can provide user management and coordinate with the PostgREST server using JWT. It's also possible to support logins entirely through SQL. It's a fair bit of work, so get ready.
 
 Storing Users and Passwords
 ---------------------------

docs/references/api/domain_representations.rst

@@ -173,4 +173,4 @@ Domain Representations avoid all the above drawbacks. Their only drawback is tha
 
   Why not create a `base type <https://www.postgresql.org/docs/current/sql-createtype.html#id-1.9.3.94.5.8>`_ instead? ``CREATE TYPE app_uuid (INTERNALLENGTH = 22, INPUT = app_uuid_parser, OUTPUT = app_uuid_formatter)``.
 
-  Creating base types need superuser, which is restricted on cloud hosted databases. Additionally this way lets “how the data is presented” dictate “how the data is stored” which would be backwards.
+  Creating base types need superuser, which is restricted on cloud hosted databases. Additionally this way lets "how the data is presented" dictate "how the data is stored" which would be backwards.

docs/references/api/resource_embedding.rst

@@ -143,7 +143,7 @@ Since the table name is plural, we can be more accurate by making it singular wi
 One-to-many relationships
 -------------------------
 
-The **foreign key reference** establishes the inverse one-to-many relationship. In this case, ``films`` returns as a JSON array because of the “to-many” end.
+The **foreign key reference** establishes the inverse one-to-many relationship. In this case, ``films`` returns as a JSON array because of the "to-many" end.
 
 .. code-block:: bash
 
@@ -1206,7 +1206,7 @@ Spread on resources forming :ref:`one-to-many <one-to-many>` and :ref:`many-to-m
      }
    ]
 
-Note that ``films`` is no longer an array of objects, unlike regularly embedding :ref:`one-to-many`. The embedded columns become arrays and they're correlated—in the above result, we can say that "Pulp Fiction" premiered in 1994 and "Reservoir Dogs" in 1992.
+Note that ``films`` is no longer an array of objects, unlike regularly embedding :ref:`one-to-many`. The embedded columns become arrays and they're correlated-in the above result, we can say that "Pulp Fiction" premiered in 1994 and "Reservoir Dogs" in 1992.
 
 Order in spread to-many
 ~~~~~~~~~~~~~~~~~~~~~~~
@@ -1302,7 +1302,7 @@ You can use multiple spreads at any level. For example, let's spread ``technical
 
 Note that:
 
-- All the ``film_*`` arrays are correlated—"Reservoir Dogs" premiered in 1992, its runtime is 1:39:00 and it has the following characters: ``[ "Mr. Pink", "Mr. White" ]``.
+- All the ``film_*`` arrays are correlated-"Reservoir Dogs" premiered in 1992, its runtime is 1:39:00 and it has the following characters: ``[ "Mr. Pink", "Mr. White" ]``.
 - The ``film_*`` arrays are ordered by ``year`` (due to ``films.order=year``).
 - The bottom level array ``film_characters`` is ordered (due to ``films.roles.order=character``).
 

docs/references/auth.rst

@@ -110,7 +110,7 @@ Symmetric Keys
 ~~~~~~~~~~~~~~
 
 Each token is cryptographically signed with a secret key. In the case of symmetric cryptography the signer and verifier share the same secret passphrase, which can be configured with :ref:`jwt-secret`.
-If it is set to a simple string value like “reallyreallyreallyreallyverysafe” then PostgREST interprets it as an HMAC-SHA256 passphrase.
+If it is set to a simple string value like "reallyreallyreallyreallyverysafe" then PostgREST interprets it as an HMAC-SHA256 passphrase.
 
 .. _asym_keys:
 

docs/references/configuration.rst

@@ -409,7 +409,7 @@ db-pool-max-idletime
   **In-Database** `n/a`
   =============== =================================
 
-   *For backwards compatibility, this config parameter is also available as “db-pool-timeout”.*
+   *For backwards compatibility, this config parameter is also available as "db-pool-timeout".*
 
    Time in seconds to close idle pool connections.
 

docs/references/connection_pool.rst

@@ -15,7 +15,7 @@ Dynamic Connection Pool
 
 To conserve system resources, PostgREST uses a dynamic connection pool. This enables the number of connections in the pool to increase and decrease depending on request traffic.
 
-- If all the connections are being used, a new connection is added. The pool can grow until it reaches the :ref:`db-pool` size. Note that it’s pointless to set this higher than the ``max_connections`` setting in your database.
+- If all the connections are being used, a new connection is added. The pool can grow until it reaches the :ref:`db-pool` size. Note that it's pointless to set this higher than the ``max_connections`` setting in your database.
 - If a connection is unused for a period of time (:ref:`db-pool-max-idletime`), it will be released.
 - For connecting to the database, the :ref:`authenticator <roles>` role is used. You can configure this using :ref:`db-uri`.
 
@@ -106,4 +106,4 @@ Also set :ref:`db-channel-enabled` to ``false`` since ``LISTEN`` is not compatib
 
 .. note::
 
-  It’s not recommended to use an external connection pooler. `Our benchmarks <https://github.com/PostgREST/postgrest/issues/2294#issuecomment-1139148672>`_ indicate it provides much lower performance than PostgREST built-in pool.
+  It's not recommended to use an external connection pooler. `Our benchmarks <https://github.com/PostgREST/postgrest/issues/2294#issuecomment-1139148672>`_ indicate it provides much lower performance than PostgREST built-in pool.

docs/references/listener.rst

@@ -4,7 +4,7 @@ Listener
 ########
 
 PostgREST uses `LISTEN <https://www.postgresql.org/docs/current/sql-listen.html>`_ to reload its :ref:`Schema Cache <schema_reloading_notify>` and :ref:`Configuration <config_reloading_notify>` via `NOTIFY <https://www.postgresql.org/docs/current/sql-notify.html>`_.
-This is useful in environments where you can’t send SIGUSR1 or SIGUSR2 Unix Signals.
+This is useful in environments where you can't send SIGUSR1 or SIGUSR2 Unix Signals.
 Like on cloud managed containers or on Windows systems.
 
 .. code:: postgresql

docs/requirements.txt

@@ -1,7 +1,7 @@
 # This file is auto-generated by postgrest-nixpkgs-upgrade
-sphinx==7.4.7
+sphinx==8.2.3
 sphinx-copybutton==0.5.2
 sphinx-rtd-dark-mode==1.3.0
 sphinx-rtd-theme==3.0.2
 sphinx-tabs==3.4.7
-sphinxext-opengraph==0.9.1
+sphinxext-opengraph==0.9.1