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.
BREAKING CHANGE: For the cases where one to one relationships are
detected, json objects will be returned instead of json arrays of length
1.
If you wish to override this behavior, you can use computed
relationships to return arrays again.
