sql: support preferred binary operators #70066
Merged
+57
−32
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This change is |
22 tasks
Needed for cockroachdb#69010. This commit adds support for "preferred" overloads of binary operators. It then uses this new support to prefer the `(jsonb, text)` overload over the `(jsonb, int)` overload of the `->` (JSONFetchVal) and `->>` (JSONFetchText) operators. This allows the type system to properly type (according to Postgres) the following statements: ```sql PREPARE x AS SELECT '{"field": 12}'->$1 PREPARE x AS SELECT '{"field": 12}'->>$1 ``` Before this commit, each would return: ```sql ERROR: unsupported binary operator: <jsonb> -> <jsonb> ``` This commit is helpful for PostgREST support. While this isn't a hard blocker, it is for use of JSON/JSONB data types with PostgREST. With this commit, and including the rest of the prototype in cockroachdb#69010, we can now handle requests like: ``` ➜ curl -s 'http://localhost:3000/vehicles?status=eq.in_use&select=city,ext->brand&ext->>color=eq.blue' | jq [ { "brand": null, "city": "boston" }, { "brand": "Pinarello", "city": "rome" }, { "brand": null, "city": "san francisco" } ] ``` One of the more subtle parts of this change is the adjustment in `typeCheckOverloadedExprs` to consider overload preference before argument homogeneity. This was necessary to avoid type checking getting tricked into wanting a `(jsonb, jsonb)` overload (see above). I confirmed that no other overloaded function that has a `PreferredOverload` has more than one argument, so these two heuristic were operating independently to this point. This means that this change shouldn't be able to cause a regression in type checking. I think the change also makes sense, as an explicit preference should overrule what is effectively a guess. Release note (sql change): Placeholder values can now be used as the right-hand operand of the JSONFetchVal (->) and JSONFetchText (->>) operators without ambiguity. This argument will be given the text type and the "object field lookup" variant of the operator will be used. Release justification: None
nvanbenschoten
force-pushed
the
nvanbenschoten/binOpPreferred
branch
from
530a27f to
b41080b
Compare
otan
approved these changes
Sep 12, 2021
|
TFTR! bors r=otan |
|
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Needed for #69010.
This commit adds support for "preferred" overloads of binary operators. It then uses this new support to prefer the
(jsonb, text)overload over the(jsonb, int)overload of the->(JSONFetchVal) and->>(JSONFetchText) operators. This allows the type system to properly type (according to Postgres) the following statements:Before this commit, each would return:
This commit is helpful for PostgREST support. While this isn't a hard blocker, it is for use of JSON/JSONB data types with PostgREST. With this commit, and including the rest of the prototype in #69010, we can now handle requests like:
One of the more subtle parts of this change is the adjustment in
typeCheckOverloadedExprsto consider overload preference before argument homogeneity. This was necessary to avoid type checking getting tricked into wanting a(jsonb, jsonb)overload (see above). I confirmed that no other overloaded function that has aPreferredOverloadhas more than one argument, so these two heuristic were operating independently to this point. This means that this change shouldn't be able to cause a regression in type checking. I think the change also makes sense, as an explicit preference should overrule what is effectively a guess.Release note (sql change): Placeholder values can now be used as the right-hand operand of the JSONFetchVal (->) and JSONFetchText (->>) operators without ambiguity. This argument will be given the text type and the "object field lookup" variant of the operator will be used.
Release justification: None