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
This is working as designed but I can see how it would be good for the design to change.
All numeric literals regardless of format (even hex) are inferred as <numeric>.
This placeholder within the type hierarchy allows them to be unified with any other numeric type. The way it currently works, if we inferred 0 as <integral> then it wouldn't unify with any types under the <fractional> branch of the hierarchy, so e.g. select SomeFloatingPointColumn + 1 wouldn't work.
When a type comes out of inference as one of those placeholders like <numeric> or <fractional> or whatever, instead of a concrete type like int64, we just default to the most general type. In the case of <numeric>decimal is considered to be the most general.
Maybe we could track a little extra information in the type so that literals like 0 can still be treated as "any ol' number" for unification purposes, but if they get through all of typechecking without further info, could get a default type assigned based on the characteristics of the literal (fits in int32? has decimal point? hex?).
If it's working as designed, then maybe all that's needed is to clarify the linked documentation, adding a bullet point to the bottom of the page to indicate that all numbers are inferred as decimal unless explicitly cast.
This vendor-specific code
infers the type of the
csum
column as decimal type. Changing the column expression tocast(0 as int)
changes the type to int.From the documentation I expect digits with no decimal point to be interpreted as an int literal.
The text was updated successfully, but these errors were encountered: