Skip to content

Conversation

@rubensantoniorosa2704
Copy link

@rubensantoniorosa2704 rubensantoniorosa2704 commented Oct 30, 2025

Problem

MySQL mathematical expressions like (a1 / 1024) were being generated as interface{} instead of proper types like sql.NullFloat64.

Root Cause

  • The IsMathematicalOperator function only supported PostgreSQL operators
  • MySQL's TiDB parser converts / to "div" operator, which wasn't recognized
  • Expression type inference was hardcoded to "int" for all mathematical operations

Solution

  1. Added MySQL "div" operator support to IsMathematicalOperator
  2. Implemented intelligent type inference that:
    • Analyzes operand types from table schemas
    • Considers operation type (division → float)
    • Combines types intelligently
    • Supports recursive expressions

Before/After

// Before:
type Row struct {
    A1Float interface{}      // ❌
    A2Float interface{}      // ❌
    A3      sql.NullFloat64  // ✅
}

// After: 
type Row struct {
    A1Float sql.NullFloat64  // ✅
    A2Float sql.NullFloat64  // ✅
    A3      sql.NullFloat64  // ✅
}
@dosubot dosubot bot added size:L This PR changes 100-499 lines, ignoring generated files. 🔧 golang labels Oct 30, 2025
@rubensantoniorosa2704 rubensantoniorosa2704 deleted the fix/mysql-div-operator-type-inference branch October 31, 2025 13:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:L This PR changes 100-499 lines, ignoring generated files. 🔧 golang

1 participant