BREAKING CHANGE
The endpoint was at risk of being left unprotected when exposing it.
The accompanying `admin-server-config-enabled` config was also dropped.
Currently it's redundant and not easy to read.
```
{"message":"JSON object requested, multiple (or no) rows returned",
"details":"The result contains 2 rows"}
```
Now:
```
{"message":"Cannot coerce the result to a single JSON object",
"details":"The result contains an array of 0 objects"}
``
Also correct docs which had a wrong error code.
It used to be that this was only enabled with log-level=debug.
But the default log-level is misleading, for example:
```
$ PGRST_DB_SCHEMAS="apflora" postgrest-with-postgresql-16 -f test/io/big_schema.sql postgrest-run
...
13/Nov/2024:22:08:20 -0500: Config reloaded
13/Nov/2024:22:08:20 -0500: Schema cache queried in 36.3 milliseconds
13/Nov/2024:22:08:20 -0500: Schema cache loaded 326 Relations, 305 Relationships, 7 Functions, 0 Domain Representations, 4 Media Type Handlers, 1194 Timezones
```
The "Schema cache loaded" can take a while to appear, yet the 22:08:20
time is the same. If we reveal the load time this is clarified:
```
13/Nov/2024:22:08:37 -0500: Schema cache loaded in 16770.1 milliseconds
```
It's important for observability to have an historic trace of the pool
size. Currently we expose it on the metrics endpoint, but not all
deployments use it.
This logs the pool size after the successful connection log to make it
more visible:
<timestamp>: Connection Pool initialized with a maximum size of 4 connections
It's not immediately clear on which port the API server is listening.
Also it's not clear that the "pgrst" channel is for database
notifications.
Goes from:
<timestamp>: Admin server listening on 0.0.0.0:3001
<timestamp>: Listening on 0.0.0.0:3000
<timestamp>: Listening for notifications on the "pgrst" channel
To:
<timestamp>: Admin server listening on 0.0.0.0:3001
<timestamp>: API server listening on 0.0.0.0:3000
<timestamp>: Listening for database notifications on the "pgrst" channel
- Fixed "column reference <col> is ambiguous" error when selecting "?select=...table(col,count())"
- Fixed "column <json_aggregate>.<alias> does not exist" error when selecting "?select=...table(aias:count())"
Fixes https://github.com/PostgREST/postgrest/issues/3523.
Now if there's a failure when obtaining the pg version OR schema cache,
we do the same retrying process. This way we don't add two retries.
Refactors and renames the "connectionWorker" to "schemaCacheLoader".
This makes more sense since what we really want is the schema cache,
the version is the pre-requisite for ensuring our
schema cache queries work.
Additionally, we no longer log ` Attempting to connect to the database...`
at startup unnecessarily. This is only logged whenever there's a retry attempt.
Wolfgang Walther