-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SQL Server: Set operations should work if normalized store type is the same #29020
Comments
Note from triage: using the store type name is not really appropriate here. For example, it will fail to indicate that "national character varying (20)" is the same as "NVARCHAR(20)". |
I wonder if we should have a way to normalize store types, yielding their canonical representation which can be compared... |
Note from triage: fix the case-sensitivity for 7.0; punt full fix. |
When implementing store type normalization, use that also when doing parameter matching in QuerySqlGenerator.VisitSqlParameter (see #29650 (comment)). |
Note from design meeting: stop throwing in this case and let the database throw if the types are not compatible. |
Note for triage: we should decide what to do about parameter matching in QuerySqlGenerator.VisitSqlParameter (see #29650 (comment)). |
Note from triage: since the VisitSqlParameter check is an optimization only, the existing check is fine. |
In
SelectExpression.cs:1594
(Microsoft.EntityFrameworkCore.Query.SqlExpression) there is code that doesIf
col1
type in mode isVARCHAR(20)
andcol2
type isvarchar(20)
it throws. This should not happen as SQL server is not case sensitive. I udestrand why it would be desirable forvarchar(20)
andvarchar(50)
to throw, but in case of case sensitivity it's exactly the same type.The text was updated successfully, but these errors were encountered: