Skip to content

Conversation

@arnaud-lacurie
Copy link
Collaborator

This commit implements a solution for GitHub issue #3743 where struct type
metadata (type names like "STRUCT_1", "STRUCT_2") was getting lost during
query execution, especially in continuations.

Problem:
When executing queries that return struct types, ResultSetMetaData would return
UUID-based names (like "id...") instead of proper struct type names. This affected:

  • Star expansion queries (SELECT * FROM table)
  • Nested star queries (SELECT (*) FROM table)
  • Direct struct projections (SELECT struct_column FROM table)
  • Query continuations (EXECUTE CONTINUATION)

Root Cause:

  1. Semantic analysis produces correct DataTypes with struct names ("STRUCT_1", etc.)
  2. Cascades planner Type.Record loses struct names during optimization (becomes null)
  3. executePhysicalPlan() previously relied only on planner types → UUID generation
  4. Continuations had no semantic type info → always generated UUIDs

Solution - Hybrid Approach:

Merge semantic type structure with planner field names:

  • Field names from planner Type.Record (handles aliases, star expansion, "_0" naming)
  • Type structure from semantic DataTypes (preserves "STRUCT_1", "STRUCT_2")
  • Additional enrichment from RecordMetaData descriptors for nested types

This commit implements a solution for GitHub issue FoundationDB#3743 where struct type
metadata (type names like "STRUCT_1", "STRUCT_2") was getting lost during
query execution, especially in continuations.

**Problem:**
When executing queries that return struct types, ResultSetMetaData would return
UUID-based names (like "id...") instead of proper struct type names. This affected:
- Star expansion queries (SELECT * FROM table)
- Nested star queries (SELECT (*) FROM table)
- Direct struct projections (SELECT struct_column FROM table)
- Query continuations (EXECUTE CONTINUATION)

**Root Cause:**
1. Semantic analysis produces correct DataTypes with struct names ("STRUCT_1", etc.)
2. Cascades planner Type.Record loses struct names during optimization (becomes null)
3. executePhysicalPlan() previously relied only on planner types → UUID generation
4. Continuations had no semantic type info → always generated UUIDs

**Solution - Hybrid Approach:**

Merge semantic type structure with planner field names:
- Field names from planner Type.Record (handles aliases, star expansion, "_0" naming)
- Type structure from semantic DataTypes (preserves "STRUCT_1", "STRUCT_2")
- Additional enrichment from RecordMetaData descriptors for nested types
@arnaud-lacurie arnaud-lacurie added the enhancement New feature or request label Nov 14, 2025
Refactored canReadStructTypeName helper to use integer parameters for
controlling base query and continuation reruns. Added tests to cover
the withExecutionContext method in ContinuedPhysicalQueryPlan, addressing
the Teamscale test gap.
@arnaud-lacurie arnaud-lacurie marked this pull request as ready for review November 17, 2025 18:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant