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.
BREAKING CHANGE
Not gzipping the output more than doubles the throughput for a simple "do nothing" RPC function.
Postgrest's gzip support was surprisingly slow, lacked in configurability, was undocumented and untested.
It was possible to achieve this before by not sending `Accept-Encoding: gzip`, but that turned into a bit of an undocumented gotcha. Most browsers do send it and by default a proxy pass would forward this header. Better to not support gzip at all, further focusing on ensuring Postgrest is a minimal layer over Postgres.
Nginx, or whatever proxy, provides critical options such as min length, vary headers and so forth, and will likely have much better performance as well.
