Correct LTree type mapping logic #2489
Conversation
| // If it's a parameter, we can also just apply the mapping (which causes NpgsqlDbType to be set to LQuery). | ||
| // For anything else, we may need an explicit cast to LQuery, e.g. a plain text column or a concatenation between strings; | ||
| // apply the default type mapping and then apply an additional Convert node if the resulting mapping isn't what we need. | ||
| private SqlExpression ApplyTypeMappingOrConvert(SqlExpression sqlExpression, RelationalTypeMapping typeMapping) |
There was a problem hiding this comment.
@smitpatel you may be interested in this. The context is that CLR string can be mapped to PG lquery; previously, functions requiring an lquery simply applied the type mapping, which didn't work for non-lquery columns (a cast node is needed), or for concatenation (since the type mapping would filter down to the operands, but concat on lquery isn't supported - the type mapping must be applied after the concatenation happens over strings).
On the other hand I don't want to just always have a convert node (don't need it for literals, parameters, or column which already are of type lquery); in that sense could be related to dotnet/efcore#26411. So there's the logic here to determine when the explicit convert is needed. May be worth thinking about in relational...
|
Backported to 6.0.7 via 9b2a90c |
Fixes #2487