In some instances where a record value of a user-defined struct type is expected, providing a constructed record of that type using the syntax STRUCT <TypeName> (...) fails. For example:
CREATE TYPE AS STRUCT TypeA(a bigint, b bigint)
CREATE FUNCTION f1(IN a TYPE TypeA) AS .....
....
SELECT f1(STRUCT TypeA (1, 2)) from range(1, 2) --> fails during plan generation
SELECT STRUCT TypeA(1, 2) from range(1, 2) --> fails after plan generation while computing required types
Both of these queries fail because they compare the type of the constructed record to the expected Record type using equals, which deems the two types as unequal because the user-defined type TypeA has nullable fields (and it must have nullable fields unless these fields are arrays), the type of the constructed record doesn't have nullable fields (as the fields are populated from literal values that can't be nullable).
Changing the definition of Type.Record::equals to compare fields ignoring their nullability breaks some existing tests, so we should figure out the best way to make this work as expected everywhere.
In some instances where a record value of a user-defined struct type is expected, providing a constructed record of that type using the syntax
STRUCT <TypeName> (...)fails. For example:Both of these queries fail because they compare the type of the constructed record to the expected Record type using
equals, which deems the two types as unequal because the user-defined typeTypeAhas nullable fields (and it must have nullable fields unless these fields are arrays), the type of the constructed record doesn't have nullable fields (as the fields are populated from literal values that can't be nullable).Changing the definition of
Type.Record::equalsto compare fields ignoring their nullability breaks some existing tests, so we should figure out the best way to make this work as expected everywhere.