See PR #2523. Most notable code changes:
- Load data representation casts into schema cache.
- Data representations for reads, filters, inserts, updates, views, over joins.
- `CoercibleField` represents name references in queries where coercion may be needed.
- `ResolverContext` help facilitate field resolution during planning.
- Planner 'resolves' names in the API query and pairs them with any implicit conversions to be used in the query builder stage.
- Tests for all of the above.
- More consistent naming (TypedX -> CoercibleX).
New: unit tests for more data representation use cases; helpful as examples as well.
New: update CHANGELOG with data representations feature description.
Fixed failing idempotence test.
New: replace date formatter test with one that does something.
Fixup: inadvertent CHANGELOG change after rebase.
Cleanup: `tfName` -> `cfName` and related.
Document what IRType means.
Formatting.
New: use a subquery to interpret `IN` literals requiring data rep transformation.
- With the previous method, very long queries such as `ANY (ARRAY[test.color('000100'), test.color('CAFE12'), test.color('01E240'), ...` could be generated. Consider the case where the parser function name is 45 characters and there's a hundred literals. That's 4.5kB of SQL just for the function name alone!
- New version uses `unnest`: `ANY (SELECT test.color(unnest('{000100,CAFE12,01E240,...}'::text[]))` to produce a much shorter query.
- This is likely to be more performant and either way much more readable and debuggable in the logs.
This returns an error for trying to update or insert into invalid columns, without hitting the database. This change also switches from `json_populate_recordset` for these operations `json_to_recordset` which should make no functional difference except allowing future flexibility.
- switch from "unknown" parameter in text format to a "json" parameter in
binary format (no dependency update required)
- use a lazy bytestring "json" encoder (via updated hasql)
* 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
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)
The request.spec GUC contains the schema cache structure in json.
It's only available when the root endpoint(/) is requested and when
db-root-spec is not empty.
Also correct db-root-spec to accept a schema.
Now that PgVersion is not part of DbStructure, Config is a more apt
module for it.
Also rename getDbStructure to queryDbStructure. AppState also had a
getDbStructure function for a record field.
