tamnd / tamnd/firepanda

The type differential does not compare 12 MAP return types, because SqlType carries one element and a map needs two

Open
#780 3 comments 0 reactions 0 assignees View on GitHub
area/sql enhancement
Dominant language
Mojo
Stars
1
Forks
0
Avg merge
1h 31m
Merged PRs (30d)
640

Description

The type differential compares `typeof()` against DuckDB over 15,001 expressions. It was binding 932 of them, across 29 function names, without comparing their type at all: both sides bound the call and the same overload won, and then the harness gave up because the signature that won did not name a type. It named a rule.

#782 read the template letters and the bare decimals, which was 820 of the 932. #784 gave `SqlType` a list element and read the list returns, which was another 100 and eight of the nine names. What is left is 12 expressions and one name.

The name is `histogram`, which returns `MAP(K, UBIGINT)` over whatever it counted. A map needs a key type and a value type where `SqlType` carries one element, so there is nowhere to put the second.

That is the decision the issue is now about, and it is not obviously worth taking. The element on `SqlType` is deliberately flat, one identifier and a width and a scale, which is a list of scalars and nothing deeper. A map would be a second triple beside the first, and a struct would be neither because it needs a list of members. Twelve probes out of 15,001 is a thin reason to grow the type, and the honest alternative is to keep printing the 12 separately and say why, which is what the harness does now.

The other half of the same question is `resolve.mojo`, which says at the top of its own file that a list argument against a list parameter matches on the shape and charges `ANY_COST` rather than charging the elements against each other. The element exists now, so that is there to be written, but nothing in tier 1 has two list overloads to choose between and the harness has no list column to measure the right answer against. Everything else in that file was measured rather than reasoned out, so it waits for a case that can be.

This also blocks an exit criterion on #308, which asks the overload resolution fuzzer to agree with DuckDB on the resolved return type for every implemented name. 12 expressions out of 15,001 is what stands between it and that.

Contributor guide

Open the contributing guide

Research direction

Start by reading the existing SqlType handling and resolve.mojo, especially the documented list-shape matching behavior. Trace how the histogram probes are handled and how the harness reports unresolved return types. Done means either a justified map-type design that resolves the 12 expressions and supports the stated exit criterion, or a documented decision to keep those probes separate and explain why.

Written by the indexing model from the issue text.

Assessment

Domain
data-engineering
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.