You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our logic for handling inline collections (VALUES) in relational currently does the same thing as for parameter collections - the type mapping is left null, and is inferred based on usage in the query (e.g. if the query's projection column is compared to an actual column, that latter column's type mapping gets inferred to the VALUES expression).
However, unlike a parameter collection, an inline collection can actually contain a column with a type mapping. For example, in the following:
The type mapping of the SQL ValuesExpression projection should just bubble up from the type mapping of b.Name. Similarly, if there are some constants/parameters in the inline collection, we should infer their type mapping from the column in the same type mapping:
We could... though note that this (and #33439) don't actually fix #33410 specifically, since that uses Union and not Concat... Also I agree that these fixes are simple enough and patchable, though this isn't exactly a one-liner either.
Should we wait for more user complaints about this first?
Our logic for handling inline collections (VALUES) in relational currently does the same thing as for parameter collections - the type mapping is left null, and is inferred based on usage in the query (e.g. if the query's projection column is compared to an actual column, that latter column's type mapping gets inferred to the VALUES expression).
However, unlike a parameter collection, an inline collection can actually contain a column with a type mapping. For example, in the following:
The type mapping of the SQL ValuesExpression projection should just bubble up from the type mapping of b.Name. Similarly, if there are some constants/parameters in the inline collection, we should infer their type mapping from the column in the same type mapping:
This is what we already do for InExpression over an inline collection, which is conceptually very similar.
Triggered by analysis by @maumar in #33410 (comment)
The text was updated successfully, but these errors were encountered: