SQL Server: Set operations should work if normalized store type is the same

[Deathrage]

In SelectExpression.cs:1594 (Microsoft.EntityFrameworkCore.Query.SqlExpression) there is code that does

if (innerColumn1.TypeMapping!.StoreType != innerColumn2.TypeMapping!.StoreType)
{
    throw new InvalidOperationException(RelationalStrings.SetOperationsOnDifferentStoreTypes);
}

If col1 type in mode is VARCHAR(20) and col2 type is varchar(20) it throws. This should not happen as SQL server is not case sensitive. I udestrand why it would be desirable for varchar(20) and varchar(50) to throw, but in case of case sensitivity it's exactly the same type.

[ajcvickers]

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)".

[roji]

I wonder if we should have a way to normalize store types, yielding their canonical representation which can be compared...

[ajcvickers]

Note from triage: fix the case-sensitivity for 7.0; punt full fix.

[roji]

When implementing store type normalization, use that also when doing parameter matching in QuerySqlGenerator.VisitSqlParameter (see https://github.com/dotnet/efcore/pull/29650#discussion_r1030251583).

[ajcvickers]

Note from design meeting: stop throwing in this case and let the database throw if the types are not compatible.

[ajcvickers]

Note for triage: we should decide what to do about parameter matching in QuerySqlGenerator.VisitSqlParameter (see https://github.com/dotnet/efcore/pull/29650#discussion_r1030251583).

[ajcvickers]

Note from triage: since the VisitSqlParameter check is an optimization only, the existing check is fine.