Types​

The foundation of EdgeQL is EdgeDB’s rigorous typesystem. There is a set of EdgeQL operators and functions for changing, introspecting, and filtering by types.

Type expressions​

Type expressions are exactly what they sound like: EdgeQL expressions that refer to a type. Most commonly, these are simply the names of established types: str, int64, BlogPost, etc. Arrays and tuples have a dedicated type syntax.

For additional details on type syntax, see Schema > Primitive Types.

Type casting​

Type casting is used to convert primitive values into another type. Casts are indicated with angle brackets containing a type expression.

select <str>10;

{"10"}

select <bigint>10;

{10n}

select <array<str>>[1, 2, 3];

{['1', '2', '3']}

select <tuple<str, float64, bigint>>(1, 2, 3);

{('1', 2, 3n)}

Type casts are useful for declaring literals for types like datetime, uuid, and int16 that don’t have a dedicated syntax.

select <datetime>'1999-03-31T15:17:00Z';

{<datetime>'1999-03-31T15:17:00Z'}

select <int16>42;

{42}

select <uuid>'89381587-705d-458f-b837-860822e1b219';

{89381587-705d-458f-b837-860822e1b219}

There are limits to what values can be cast to a certain type. In some cases two types are entirely incompatible, like bool and int64; in other cases, the source data must be in a particular format, like casting str to datetime.

select <BlogPost>10;

QueryError: cannot cast 'std::int64' to 'default::BlogPost'

select <int64>'asdf';

InvalidValueError: invalid input syntax for type std::int64: "asdf"

select <int16>100000000000000n;

NumericOutOfRangeError: std::int16 out of range

For a comprehensive table of castability, see Standard Library > Casts.

Type intersections​

Type casts can only be used on primitive expressions, not object type expressions. Every object stored in the database is strongly and immutably typed; you can’t simply convert an object to an object of a different type.

All elements of a given set have the same type; however, in the context of sets of objects, this may be misleading. A set of Animal objects may contain instances of multiple subtypes, like Cat and Dog.

select Animal;

{
  default::Dog {id: 9d2ce01c-35e8-11ec-acc3-83b1377efea0},
  default::Dog {id: 3bfe4900-3743-11ec-90ee-cb73d2740820},
  default::Cat {id: b0e0dd0c-35e8-11ec-acc3-abf1752973be},
}

We can use the type intersection operator to restrict the elements of a set by subtype.

select Animal[is Dog];

{
  default::Dog {id: 9d2ce01c-35e8-11ec-acc3-83b1377efea0},
  default::Dog {id: 3bfe4900-3743-11ec-90ee-cb73d2740820},
}

Logically, this computes the intersection of the Animal and Dog sets; since only Dog objects occur in both sets, this can be conceptualized as a “filter” that removes all elements that aren’t of type Dog.

Type checking​

The [is foo] “type intersection” syntax should not be confused with the type checking operator is.

select 5 is int64;

{true}

select {3.14, 2.718} is not int64;

{true, true}

select Animal is Dog;

{true, true, false}

The typeof operator​

The type of any expression can be extracted with the typeof operator. This can be used in any expression that expects a type.

select <typeof 5>'100';

{100}

select "tuna" is typeof "trout";

{true}

Introspection​

The entire typesystem of EdgeDB is stored inside EdgeDB. All types are introspectable as instances of the schema::Type type. For a set of introspection examples, see Guides > Introspection.