Module bool_exp 

Boolean expression input types.

Hasura’s filter argument is where: <table>_bool_exp – a generated input object with one field per column, one per relationship, and _and, _or and _not for structure:

author(where: {_and: [{id: {_gt: 2}},
                      {articles: {title: {_ilike: "%rust%"}}}]}) { id }

The shape matters more than it looks. A JSON argument accepts the same text, but nothing downstream can read it: a client cannot generate types from it, an editor cannot complete it, and a typo in an operator name reaches the server instead of being refused by the client. Every case in Hasura’s introspection corpus turns on these types existing, and so does every graphql-codegen run a migrating client has in its build.

Two naming rules, both taken from what a client has already compiled against rather than from taste:

• The table’s expression is <table>_bool_exp, named for the table exactly as it is spelled in PostgreSQL. It appears in the client’s own source wherever a query declares a variable.
• A column’s expression is named for the column’s scalar type, so every text column in the schema shares one String_comparison_exp.

Constants

AGGREGATE_PREDICATES

The aggregates a predicate may be written over.

Functions

aggregate_bool_exp_columns

The name of the enum naming the columns bool_and and bool_or may take.

aggregate_bool_exp_function

The name of one aggregate’s own input inside that.

aggregate_bool_exp_type_name

The name of a table’s aggregate boolean expression input.

bool_exp_type_name

The name of a table’s boolean expression input.

build_inputs

Every input type the boolean expressions need, ready to register, and every scalar those inputs name.

comparison_type_name

The name of the comparison input for a scalar.

ltree_operator

The operator each tree comparison becomes, and what its operand is cast to.

postgis_function

The PostGIS function behind each of those, and behind the ones that take more than a shape.