- Revert patch #2311
- Keep the refactor done to qsFiltersRoot
- Keep the refactor done to the items tables
- Add tests that now work with pg-safeupdate as a result
Previously, it was quite possible to have two connection workers
running, or to get into a state where a failed connection worker
is still considered running preventing new connection workers
from starting.
* limited update/delete now works on views with explicit order
* no default order, enforce order presence
* apply row count to ensure limited mutations
* move requiring order to ApiRequest
Only add m2m relationship based on real junctions:
a table has FKs to two other tables and the FK columns
are part of the PK columns.
Also add some stats to big_schema.sql
* Get PKcols inside tables - done with SQL for tables and
with an additional step in Haskell for views.
This fixes an fk column being considered as a pk column on views
and corrects the test added on
https://github.com/PostgREST/postgrest/pull/1875/files/1d549768580310e18aac4ffa6dbd01c5b77934a7#r853674126
* classify view key dependencies in SQL
* remove Column from Relationship
* Merge cols/fcols in Relationship and
ensure allM2ORels and allViewsKeyDependencies fk columns
are ordered - done by attnum in SQL
* Cardinality now contains relColumns instead of Relationship -
this simplifies getJoinConditions.
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.
