Using GET with text/plain or application/octet-stream as Content-Type headers no longer returns 404 Not Found when a function with no parameters exists
Aggregates and Window functions can't be called as RPCs in a useful way.
Procedures are not supported right now, but might be added later.
Resolves#2101
Signed-off-by: Wolfgang Walther <walther@technowledgy.de>
The PG version is only read by the Connection Worker, which is not used in the case dump-schema. Now, the pg version is read in the schema cache queries directly, avoiding this problem in all cases.
Signed-off-by: Wolfgang Walther <walther@technowledgy.de>
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
