Enum sql::func::ParamList[−][src]

pub enum ParamList {
    Exact(Vec<ParamType>),
    Variadic(ParamType),
}

Expand description

Describes possible types of function parameters.

Note that this is not exhaustive and will likely require additions.

Variants

`Variadic(ParamType)`

Tuple Fields

0: ParamType

Implementations

[src]

impl ParamList

[src]

fn matches_argtypes(
 &self,
 ecx: &ExprContext<'_>,
 typs: &[Option<ScalarType>]
) -> bool

Determines whether typs are compatible with self.

[src]

fn validate_arg_len(&self, input_len: usize) -> bool

Validates that the number of input elements are viable for self.

[src]

fn has_polymorphic(&self) -> bool

Reports whether the parameter list contains any polymorphic parameters.

[src]

fn resolve_polymorphic_types(
&self,
typs: &[Option<ScalarType>]
) -> Option<ScalarType>

Enforces polymorphic type consistency by finding the concrete type that satisfies the constraints expressed by the polymorphic types in the parameter list.

Polymorphic type consistency constraints include:

All arguments passed to ArrayAny must be ScalarType::Arrays with the same types of elements. All arguments passed to ArrayElementAny must also be of these elements’ type.
All arguments passed to ListAny must be ScalarType::Lists with the same types of elements. All arguments passed to ListElementAny must also be of these elements’ type.
All arguments passed to MapAny must be ScalarType::Maps with the same type of value in each key, value pair.

Returns Some if the constraints were successfully resolved, or None otherwise.

Custom types

Materialize supports two classes of types:

Custom types, which are defined by CREATE TYPE or contain a reference to a type that was.
Built-in types, which are all other types, e.g. int4, int4 list.

Among built-in types there are:
- Complex types, which contain references to other types
- Simple types, which do not contain referneces to other types

To support accepting custom type values passed to polymorphic parameters, we must handle polymorphism for custom types. To understand how we assess custom types’ polymorphism, it’s useful to categorize polymorphic parameters in MZ.

Complex parameters include complex built-in types’ polymorphic parameters, e.g. ListAny and MapAny.

Valid ScalarTypes passed to these parameters have a custom_oid field and some embedded type, which we’ll refer to as its element.
Element parameters which include ArrayElementAny, ListElementAny and NonVecAny.

Note that:

Custom types can be used as values for either complex or element parameters; we’ll refer to these as custom complex values and custom element values, or collectively as custom values.
ArrayAny is slightly different from either case, but is uncommonly used and not addressed further.

Resolution

Upon encountering the first custom complex value:
- All other custom complex types must exactly match both its custom_oid and embedded element.
- All custom element types must exactly match its embedded element type.
One of the complexities here is that the custom complex value’s element can be built-in type, meaning any custom element values will cause polymorphic resolution to fail.
Upon encountering the first custom element value:
- All other custom element values must exactly match its type.
- All custom complex types’ embedded elements must exactly match its type.

Custom + built-in types

If you use both custom and built-in types, the resultant type will be the least-custom custom type that fulfills the above requirements.

For example if you list_append(int4 list list, custom_int4_list), the resulant type will be complex: its custom_oid will be None, but its embedded element will be the custom element type, i.e. custom_int4_list list).

However, it’s also important to note that a complex value whose custom_oid is None are still considered complex if its embedded element is complex. Consider the following scenario:

CREATE TYPE int4_list_custom AS LIST (element_type=int4);
CREATE TYPE int4_list_list_custom AS LIST (element_type=int4_list_custom);
/* Errors because we won't coerce int4_list_custom list to
   int4_list_list_custom */
SELECT '{{1}}'::int4_list_list_custom || '{{2}}'::int4_list_custom list;

We will not coerce int4_list_custom list to int4_list_list_custom––only built-in types are ever coerced into custom types. It’s also trivial for users to add a cast to ensure custom type consistency.

[src]