Rezoom.SQL icon indicating copy to clipboard operation
Rezoom.SQL copied to clipboard

Integer literal in `imagine` block inferred as decimal type

Open adam-c-anderson opened this issue 8 years ago • 2 comments

This vendor-specific code

    vendor tsql {
        select *, checksum(*) as csum from person
    } imagine {
        select *, 0 as csum from person
    }

infers the type of the csum column as decimal type. Changing the column expression to cast(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.

adam-c-anderson avatar Oct 19 '17 21:10 adam-c-anderson

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

rspeele avatar Oct 20 '17 23:10 rspeele

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.

adam-c-anderson avatar Oct 20 '17 23:10 adam-c-anderson