* add domain representations
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* add custom domain subheading and TOC
this way it can be seen at the beggining there are advantages over views
and computed fields.
* important note for scache reloading
* clarify advantages
* why not create a type?
---------
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
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.
* Clarify vnd.pgrst.object+json is also Content-Type
The previous docs explained how the `Accept` header could be set to
`application/vnd.pgrst.object+json`. This change indicates the resulting
response `Content-Type` begins likewise.
While robust clients will correctly identify that
`application/vnd.pgrst.object+json` data are json, many others which
naively check the `Content-Type` is `application/json` will fail to
recognize what should be a valid `Content-Type`.
