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
For some store types, their literal SQL representation automatically gets evaluated by the database to be that type; this is the case e.g. for int (SELECT 8 returns an int). But for others that's not the case, i.e. the literal representation of smallint is also 8, but that gets evaluated as int.
We can add a flag on our type mappings which says if the SQL literal representation maps back to the type; this could allow us to omit explicit conversions in some cases.
When generating a VALUES expression, we add explicit conversion to make sure the right store type comes out.
Note relationship with #27150: the literal representation of bool in SQL Server is CAST(1 AS BIT), which is there to fix mitigate #24075 (projecting out), but causes perf issues. We could try to add the CAST only where needed (VALUES, when projecting out) rather than everywhere.
The text was updated successfully, but these errors were encountered:
For some store types, their literal SQL representation automatically gets evaluated by the database to be that type; this is the case e.g. for int (
SELECT 8
returns an int). But for others that's not the case, i.e. the literal representation ofsmallint
is also 8, but that gets evaluated as int.We can add a flag on our type mappings which says if the SQL literal representation maps back to the type; this could allow us to omit explicit conversions in some cases.
Note relationship with #27150: the literal representation of bool in SQL Server is
CAST(1 AS BIT)
, which is there to fix mitigate #24075 (projecting out), but causes perf issues. We could try to add the CAST only where needed (VALUES, when projecting out) rather than everywhere.The text was updated successfully, but these errors were encountered: