Skip to content

[CALCITE-7658] Type checker rejects CAST(ARRAY() AS ROW(x INT) ARRAY)#5104

Merged
mihaibudiu merged 1 commit into
apache:mainfrom
mihaibudiu:issue7658
Jul 17, 2026
Merged

[CALCITE-7658] Type checker rejects CAST(ARRAY() AS ROW(x INT) ARRAY)#5104
mihaibudiu merged 1 commit into
apache:mainfrom
mihaibudiu:issue7658

Conversation

@mihaibudiu

Copy link
Copy Markdown
Contributor

Jira Link

CALCITE-7658

Changes Proposed

I have left this PR as two commits, which could be merged separately. I could also file separate JIRA issues for them.
They both involve the handling of the UNKNOWN type, which is the type inferred for the elements of an empty array, for example.
The JIRA explains the rationale behind these changes.

Briefly:

ARRAY(ARRAY(), ARRAY(2)) should infer finally a type of ARRAY(INT) for the first array.
CAST(ARRAY() AS ROW(x INT) ARRAY) should be a legal program.

@xuzifu666 xuzifu666 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, only left 2 minor comments.

// without constraining the result.
// Note that UNKNOWN can be nullable, so this information is carried over to the result.
List<RelDataType> knownTypes = new ArrayList<>(types.size());
// True if any UNKNONW type is nullable

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UNKNONW -> UNKNOWN

}

/** UNKNOWN types in leastRestrictive() affect only the result nullability. */
@Test void testLeastRestrictiveWithUnknown() {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current test only covers a single UNKNOWN case; could we consider adding a test case that mixes multiple UNKNOWNs with known types, for example:

RelDataType r = f.typeFactory.leastRestrictive(
    Lists.newArrayList(f.sqlUnknown, f.sqlUnknown, f.sqlBigInt));
assertThat(r.getFullTypeString(), is(f.sqlBigInt.getFullTypeString()));

This explicitly guarantees that any number of UNKNOWNs at any position will not affect the result.
Of course, this is just my understanding; feel free to take it into account.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be very good coverage for non-UNKNOWN types, and this PR only reduces the case with UNKNOWN to the case without.

@mihaibudiu mihaibudiu added the LGTM-will-merge-soon Overall PR looks OK. Only minor things left. label Jul 16, 2026
@xuzifu666

Copy link
Copy Markdown
Member

There are currently two commits in this PR; please remember to squash them before merging.

@mihaibudiu

Copy link
Copy Markdown
Contributor Author

Well, I said above that the commits are independent, and could be merged separately. In other projects they would.

Signed-off-by: Mihai Budiu <mbudiu@feldera.com>
@mihaibudiu
mihaibudiu merged commit 4c58bdb into apache:main Jul 17, 2026
16 of 17 checks passed
@mihaibudiu
mihaibudiu deleted the issue7658 branch July 17, 2026 17:47
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

LGTM-will-merge-soon Overall PR looks OK. Only minor things left.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants