Relevant Issue/Bug

The SQL specification only defines SMALLINT and INT with implementation defined precision. The only constraint is that both have precision, that precision is of the same type, and SMALLINT <= INT.

24. INTEGER specifies the data type exact numeric, with binary or decimal precision and scale of 0
    (zero). The choice of binary versus decimal precision is implementation-defined, but shall be the
    same as SMALLINT.
25. SMALLINT specifies the data type exact numeric, with scale of 0 (zero) and binary or decimal
    precision. The choice of binary versus decimal precision is implementation-defined, but shall be
    the same as INTEGER. The precision of SMALLINT shall be less than or equal to the precision
    of INTEGER.

PartiQL has implemented as,

• SMALLINT -> 16-bit signed integer
• INT4 -> 32-bit signed integer
• BIGINT -> 64-bit signed integer
• INT -> Ion's unconstrained unsigned integer

The bug is that this does not conform to the SQL standard. In particular,

The choice of binary versus decimal precision [for SMALLINT] is implementation-defined, but shall be
the same as INTEGER.

PartiQL has this wrong for two reasons

1. INTEGER must have a defined precision which PartiQL INT lacks.
2. SMALLINT has a defined precision, but INTEGER does not. SQL says they must be the same type.

Additionally (but not a bug) we need better align with most database systems which do

SMALLINT < INT < BIGINT

Requested Solution/Feature

The INTEGER|INT type has 32-bit precision.

Describe Alternatives

There are no alternatives as this is prescribed by SQL, but it is worth mentioning that you can get around this issue by using INT4 instead of INTEGER|INT — however the latter aliases are required by SQL.

Additional Context

N/A

DoD (Definition of Done)

• The INTEGER type is 32-bit precision
• Planner/typer updated to use INT rather than INT4
• There is an unconstrained integer equivalent such as decimal(38,0)?