Trigger functions can't be called directly from SQL and can't be called
via the /rpc prefix either - it makes no sense to expose them in the
OpenAPI output. And we don't need to cache them in the schema cache
either.
Best practice would be to keep the trigger functions in a non-exposed
schema anyway.
Avoids the breaking change in #1927: If there's a function "my_func" having a single unnamed json param and other overloaded pairs(with any number of params), PostgREST won't be able to resolve a POST request to "my_func".
Getting the value for a header GUC on PostgreSQL v14 is done using `current_setting('request.headers')::json->>'name-of-header'` and in a similar way for `request.cookies` and `request.jwt.claims`
PostgreSQL versions below 14 can opt in to the new JSON GUCs by setting the `db-use-legacy-gucs` config option to false (true by default)
This is enabled by adding `!inner` to the embedded resource
/projects?select=*,clients!inner(*)&clients.id=eq.12
This behaviour can be enabled by default with the config option
db-embed-default-join='inner'
Which saves the need for specifying `!inner` on every request.
If this is enabled, the previous behavior can be restored
per request by specifying `!left` on the embedded resource.
/projects?select=*,clients!left(*)&clients.id=eq.12`
Tested on M20/02M/M2M relationships, views, RPC.
For POST on RPC, allows:
* passing a json object without using `Prefer: params=single-object`
The function must be defined with a single unnamed json param and
`Content-Type: application/json` must be specified.
* uploading binary to a function
The function must be defined with a single unnamed bytea param and
`Content-Type: application/octet-stream` must be specified.
* uploading raw text to a function
The function must be defined with a single unnamed text param and
`Content-Type: text/plain` must be specified.
BREAKING CHANGE If there's a function "my_func" having a single
unnamed json param and other overloaded pairs(with any number of
params), PostgREST won't be able to resolve a POST request to
"my_func". For solving this, you can name the unnamed json param.
my_func(json) -> my_func(prm json)
* Removed some entries that were fixes for the nigthly versions, not
stable versions.
* Reference the actual issue number(not the PR number) on some entries
* Remove duplicate entries
* Clarify some entries
* Grouped CLI entries
BREAKING CHANGE
Not gzipping the output more than doubles the throughput for a simple "do nothing" RPC function.
Postgrest's gzip support was surprisingly slow, lacked in configurability, was undocumented and untested.
It was possible to achieve this before by not sending `Accept-Encoding: gzip`, but that turned into a bit of an undocumented gotcha. Most browsers do send it and by default a proxy pass would forward this header. Better to not support gzip at all, further focusing on ensuring Postgrest is a minimal layer over Postgres.
Nginx, or whatever proxy, provides critical options such as min length, vary headers and so forth, and will likely have much better performance as well.
* Include hidden views from the search path. Hidden views are views in unexposed schemas that are part of a view dependency chain.
* Change allSourceColumns to only return pk and fk columns
Fixes https://github.com/PostgREST/postgrest/issues/1512
Helps on environments where you can't send unix signals(Windows, managed
containers). Also provides better UX for schema reloads - NOTIFY
can be sent from pg clients(psql, pgadmin).
`NOTIFY pgrst` - with no payload - should be done to reload the schema cache.
Notifications with a payload will be ignored.
The channel can be enabled with `db-channel-enabled`(false by default)
and its name can be configured with `db-channel`.
The LISTEN thread uses a dedicated pg connection.
This connection is recovered if it fails.
A debounce of 1ms is done in case too many NOTIFYs arrive.
