* 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
toSourceRel is an expensive operation since it iterates over all the
relationships detected. We now use an alias on the CTE so embedding can
work without toSourceRel.
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
* Remove Table from Column
* Correct OpenAPI test where the schema was appearing for the enum unnecessarily
* Increase memory-tests consumption by 2M
Seems the Hasql decoder consumes more memory now that the allTables
results also have [Column] inside.
* 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.
Just having the QualifiedIdentifier gets us closer to having
Relationship as a Table attribute since it avoids a cyclic dependency
* remove unnecessary findTable
* modify RootSpec test
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.