It’s possible to explicitly `cast`

between all numeric types. All numeric types can also be cast to and
from `str`

and `json`

.

Arbitrary precision integer.

The EdgeDB philosophy is that using bigint type should be an explicit opt-in, but once used, the values should not be accidentally cast into a numeric type with less precision.

In accordance with this the mathematical functions are designed to keep the separation between bigint values and the rest of the numeric types.

All of the following types can be explicitly cast into bigint:
`str`

, `json`

, `int16`

,
`int32`

, `int64`

, `float32`

,
`float64`

, and `decimal`

.

A bigint literal is an integer literal followed by ‘n’:

Copy

db>

`SELECT 42n IS bigint;`

{true}

To represent really big integers it is possible to use the
exponent notation (e.g. `1e20n`

instead of `100000000000000000000n`

)
as long as the exponent is positive and there is no dot anywhere.

Copy

db>

`SELECT 1e+100n IS bigint;`

{true}

When a float literal is followed by ‘n’ it produces a
`decimal`

instead:

Copy

db>

`SELECT 1.23n IS decimal;`

{true}

Copy

db>

`SELECT 1.0e+100n IS decimal;`

{true}

Caution is advised when casting `bigint`

values into
`json`

. The JSON specification does not have a limit on
significant digits, so a `bigint`

number can be losslessly
represented in JSON. However, JSON decoders in many languages
will read all such numbers as some kind of 32- or 64-bit
number type, which may result in errors or precision loss. If
such loss is unacceptable, then consider casting the value
into `str`

and decoding it on the client side into a more
appropriate type.

Any number of arbitrary precision.

The EdgeDB philosophy is that using a decimal type should be an explicit opt-in, but once used, the values should not be accidentally cast into a numeric type with less precision.

In accordance with this the mathematical functions are designed to keep the separation between decimal values and the rest of the numeric types.

All of the following types can be explicitly cast into decimal:
`str`

, `json`

, `int16`

,
`int32`

, `int64`

, `float32`

,
`float64`

, and `bigint`

.

A decimal literal is a float literal followed by ‘n’:

Copy

db>

`SELECT 1.23n IS decimal;`

{true}

Copy

db>

`SELECT 1.0e+100n IS decimal;`

{true}

Note that an integer literal (without a dot or exponent) followed
by ‘n’ produces a `bigint`

. A literal without a dot
and with a positive exponent makes a `bigint`

, too:

Copy

db>

`SELECT 42n IS bigint;`

{true}

Copy

db>

`SELECT 12e+34n IS bigint;`

{true}

Caution is advised when casting `decimal`

values into
`json`

. The JSON specification does not have a limit on
significant digits, so a `decimal`

number can be losslessly
represented in JSON. However, JSON decoders in many languages
will read all such numbers as some kind of floating point
values, which may result in precision loss. If such loss is
unacceptable, then consider casting the value into `str`

and
decoding it on the client side into a more appropriate type.

Auto-incrementing sequence of `int64`

.

This type can be used to create auto-incrementing properties.

Copy

```
scalar type TicketNo extending sequence;
type Ticket {
property number -> TicketNo {
constraint exclusive;
}
}
```

The sequence is bound to the scalar type, not to the property, so
if multiple properties use the same `sequence`

type they will
share the same counter. For each distinct counter, a separate
scalar type that is extending `sequence`

should be used.

Scalar type
SDL,
DDL,
introspection,
arithmetic operators and numeric converter functions,
mathematical functions,
`max()`

,
`min()`

,
`random()`

,
`round()`

,
`sum()`

.