resolves#1584
BREAKING CHANGE:
Changed output of RPCs to match return type better:
* single scalar return: value (unchanged)
* setof scalar return: array of values (new; was array of objects)
* single composite return: object (new; was array of objects)
* setof composite return: array of objects (unchanged)
* void return: nothing (new; was "null")
A single OUT column is now treated as "composite" instead of "scalar",
i.e. consistent with multiple OUT columns.
resolves#1608
Refactors the pfkSourceColumns query to use an intermediate JSON format
for parsing. This allows much more robust extraction of source columns.
- Parametrize filters
- Parametrize LIMIT/OFFSET
- Parametrize JSON path(select=col->$1)
- Single parameter for IN(use ANY)
- Also enable prepared statement for the EXPLAIN
used on the estimated count.
* 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
The changes here are from fixing stack build with LTS 15.8 (GHC 8.8.3)
to be warning-free. Most if not all come from the newer protolude
version, which adds some things like `unwords`.
So to make sure that we don't get unused import warnings with newer
stackage, this both raises the protolude lower bound and removes
these imports.
* add tests for POST, PATCH, DELETE when using ?select= with empty bodies or ret=min
* fix select with empty bodies and ret=min
* improved tests for default cases, fixed computed overloaded columns on empty-body?select= PATCH
Makes previous duck typing regex unnecessary since the FK can be renamed
to a singular name or to any other format.
* Remove embedding with duck typed column names
* Allow embedding by foreign key name
* Add junction disambiguation tests
When having one-to-many relationships like:
person -< message[sender]
person -< message[recipient]
person_detail -< message[sender]
person_detail -< message[recipient]
Where person_detail is a view of person.
This request:
GET "/message?select=*,sender(*)"
Is ambiguous. Both person or person_detail could be embedded.
Until now we have returned the first detected relationship but
now we return a 300 Multiple Choices error with a
descriptive error message asking the user to disambiguate.
This is more helpful for the user and also aids in cases of more
complex relationships.
PATCH/DELETE can now be done without adding Prefer return=minimal when
the user doesn't have SELECT privileges.
* Also fix PATCH wrong HTTP status code
