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
{{ message }}
Repository navigation
Allow changing CLR type in query translation without additional SQL #33733
In some rare cases, during query translation we want to change the CLR type, but without an actual SQL conversion being necessary. For example, if an enum that's value-converted to string has ToString() called on it, nothing needs to be done in SQL (the database value is already a string), but in the query tree we need to switch from the enum type to string.
Ideally we'd be able to simply replace the enum-typed node with an identical string-typed node - but there's no reliable way to change all node types (column, function call...), unless we introduce e.g. an abstract WithType() to SqlExpression.
The alternative way would be to add a special conversion node - which would extend SqlExpression - but to simply skip it in SQL generation. The disadvantage here is that any sort of pattern matching on the node would fail (e.g. is this node a column?).
In the meantime, we'd applying a SQL conversion, which should be a no-op.
After looking into #39146 and the original enum ToString() translation in #33706, I understand the underlying requirement as allowing a SqlExpression to expose a different CLR type without requiring a corresponding SQL CAST.
Before starting an implementation, I'd like to confirm the preferred design direction. The issue mentions two possible approaches:
adding something like WithType() across SqlExpression nodes while preserving the existing SQL expression shape; or
introducing a dedicated CLR-type conversion expression which would be omitted during SQL generation.
Would a contribution exploring either of these approaches be welcome? If so, is there a preferred direction, or a narrower initial scope you would recommend?
Activity
z0rimo commentedon Oct 8, 2026
I'd be interested in working on #33733.
After looking into #39146 and the original enum
ToString()translation in #33706, I understand the underlying requirement as allowing aSqlExpressionto expose a different CLR type without requiring a corresponding SQL CAST.Before starting an implementation, I'd like to confirm the preferred design direction. The issue mentions two possible approaches:
WithType()acrossSqlExpressionnodes while preserving the existing SQL expression shape; orWould a contribution exploring either of these approaches be welcome? If so, is there a preferred direction, or a narrower initial scope you would recommend?
AndriySvyryd commentedon Oct 21, 2026
@z0rimo Sure, the latter approach should be simpler to implement.