Skip to content
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

Query: TypeCompatibility chart for inference #15586

Open
smitpatel opened this issue May 2, 2019 · 3 comments
Open

Query: TypeCompatibility chart for inference #15586

smitpatel opened this issue May 2, 2019 · 3 comments

Comments

@smitpatel
Copy link
Contributor

When we generate SQL like [c].[DoubleColumn] * 5 = 88 the inferred TypeMapping for constants become DoubleTypeMapping. In order to print out constant we cast value to double which throws following exception.
Message: System.InvalidCastException : Unable to cast object of type 'System.Int32' to type 'System.Double'.

Given operator upcasting, we don't need to use DoubleTypeMapping to print 5/88, we can just use int (or whatever type it is). But in order for us to do that, we need the logic in inference.

@roji
Copy link
Member

roji commented Jul 30, 2019

Note impact on set operations, where we have different store types coming out of the two sides but it's OK since they're implicitly convertible (see #16813 (comment)).

We may even consider a chart detailing explicit convertibility, to know which store types can be cast to which other types. This would allow us to add SQL casts if necessary.

@smitpatel
Copy link
Contributor Author

Explicit would be bad idea from provider side because if unknown types encountered you wouldn't know. Implicit side much better that you can be certain you don't need cast. In the absence of which it would be always casted.

@roji
Copy link
Member

roji commented Apr 25, 2022

Note additional interesting case: Npgsql translates NewArrayExpression, and infers type mappings across all the provided elements. Heterogeneous/incompatible elements cause an exception (the array must be of a single PG type), but we do support heterogeneous elements when they're implicitly convertible to one another (e.g. same base type with different facet, or even varchar(15) and text). This is currently "hacked" here, but a type compatibility chart would make this better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants