Support more types of parameters to JSON path#12682
Conversation
|
For completeness, this is per section 10.12.3 - JSON value expression of the SQL specification:
|
There was a problem hiding this comment.
Why do we need to track these explicitly? It should be sufficient to just register a coercion via addOrReplaceExpressionsCoercion.
There was a problem hiding this comment.
I considered that approach, but so far that mechanism was only used for implicit coercions. I didn't want to mix in the JSON path parameter coercions, which are part of JSON functions semantics rather than SQL type alignment.
There was a problem hiding this comment.
That mechanism is for anything where the analyzer decides a cast needs to be inserted, so it should be safe to use here. The concept of whether an implicit coercion is allowed is an analysis time concern and the planner doesn't care about why a cast needs to be inserted.
There was a problem hiding this comment.
In fact, we could say that this is an implicit coercion, just in a very narrow scope (json function parameters)
There was a problem hiding this comment.
I switched to the existing mechanism (addOrReplaceExpressionsCoercion).
Yes, that was the intention behind the code from the start. I just chose the wrong check: |
95d4566 to
ed4a3f4
Compare
Before this change, the JSON path parameters could be only numeric, boolean, datetime and string values, and other values that could be implicitly coerced to varchar. After this change, any values are accepted which can be coerced to varchar. It is no more required that an implicit coercion is defined.
ed4a3f4 to
3133b2c
Compare
Before this change, path parameters could be only: numeric, boolean, datetime
and string values, and other values that could be implicitly coerced to varchar.
After this change, any values are accepted which can be coerced
to varchar. It is no more required that an implicit coercion is defined.