feat(parser): Snowflake LIKE ANY/ALL and ILIKE ANY/ALL (#483)

[ajitpratap0]

Summary

Adds Snowflake `LIKE ANY/ALL` and `ILIKE ANY/ALL` pattern matching with tuple lists.

What now parses

• `WHERE name LIKE ANY ('%alice%', '%bob%')`
• `WHERE name LIKE ALL ('%a%', '%b%')`
• `WHERE msg ILIKE ANY ('%error%', '%warn%')`
• `WHERE name NOT LIKE ANY ('%test%', '%demo%')`

Implementation

After consuming `LIKE`/`ILIKE`, check for `ANY`/`ALL` quantifier tokens. If present, compose operator as `"LIKE ANY"` / `"ILIKE ALL"`, then parse the `(...)` tuple via the existing `parsePrimaryExpression` (which handles parenthesised tuples). Result is a standard `BinaryExpression` with the quantified operator string and a tuple RHS.

Test plan

• `TestSnowflakeLikeAnyAll`: 5 shapes including NOT variants
• `go test -race ./pkg/sql/parser/ ./pkg/gosqlx/` green

Part of #483.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
gosqlx-website	Ready	Preview, Comment	Apr 9, 2026 6:34pm

[github-actions]

Claude finished @ajitpratap0's task —— View job

---

Code Review: Snowflake LIKE ANY/ALL Implementation

Completed comprehensive review of the Snowflake LIKE ANY/ALL and ILIKE ANY/ALL pattern matching implementation.

Todo List

• Analyze the parser implementation changes
• Review test coverage and quality
• Check for potential bugs and edge cases
• Assess performance considerations
• Verify security implications
• Check adherence to project patterns

---

✅ Overall Assessment: APPROVED

This is a well-implemented, focused feature addition that correctly follows the project's patterns and conventions.

📋 Detailed Review

Code Quality: Excellent

The implementation in pkg/sql/parser/expressions_operators.go:113-135 is:

• Clean and readable: Clear variable naming and logical flow
• Well-documented: Excellent inline comments explaining the Snowflake syntax
• Consistent: Follows existing parser patterns for LIKE/ILIKE handling
• Properly integrated: Leverages existing parsePrimaryExpression() for tuple parsing

Implementation Details: Sound

✅ Correct operator composition: "LIKE ANY", "ILIKE ALL" etc.
✅ Proper token consumption: Consumes LIKE/ILIKE, then ANY/ALL, then expects (
✅ Reuses existing logic: Uses parsePrimaryExpression() which handles tuples correctly
✅ Standard AST structure: Creates BinaryExpression with quantified operator string
✅ NOT support: Correctly handles NOT LIKE ANY/ALL via existing notPrefix logic

Test Coverage: Comprehensive

The test file pkg/sql/parser/snowflake_like_any_all_test.go covers:

• ✅ Basic LIKE ANY and LIKE ALL patterns
• ✅ ILIKE ANY variant (case-insensitive)
• ✅ NOT LIKE ANY and NOT ILIKE ALL negations
• ✅ Proper Snowflake dialect restriction
• ✅ Integration with high-level gosqlx.ParseWithDialect() API

Suggestion: Consider adding edge case tests:

// Empty tuple test
"empty_tuple": `SELECT * FROM t WHERE name LIKE ANY ()`
// Single element tuple
"single_tuple": `SELECT * FROM t WHERE name LIKE ANY ('%test%')`

Security: No Concerns

• ✅ No new attack vectors introduced
• ✅ Reuses existing, safe tuple parsing logic
• ✅ Properly validates syntax before proceeding
• ✅ Standard error handling with location information

Performance: Optimal

• ✅ Zero overhead: Only executes when ANY/ALL tokens present
• ✅ O(1) token checks: Uses efficient isType() checks
• ✅ Memory efficient: Leverages object pooling from parsePrimaryExpression()
• ✅ No new allocations: Reuses existing AST structures

Edge Cases & Error Handling

✅ Missing parentheses: Line 123 properly expects ( after ANY/ALL
✅ Malformed tuples: Delegated to parsePrimaryExpression() which handles validation
✅ Dialect restriction: No explicit check, but ILIKE validation covers most cases

Minor Enhancement Opportunity: Consider explicit dialect checking:

// After line 117, add:
if p.dialect != "" && p.dialect != string(keywords.DialectSnowflake) {
    return nil, fmt.Errorf("LIKE %s is Snowflake-specific", quantifier)
}

Integration & Consistency

✅ Follows project patterns: Mirrors existing ANY/ALL subquery logic (lines 297-335)
✅ Consistent error handling: Uses p.expectedError() helper
✅ Proper AST generation: Creates standard BinaryExpression nodes
✅ Memory management: Delegates to pooled expressions via parsePrimaryExpression()

🎯 Recommendations

1. Ship as-is: This implementation is production-ready
2. Consider adding: Explicit Snowflake dialect validation for better error messages
3. Future enhancement: Edge case tests for empty/single-element tuples

🔄 Part of Larger Epic

This cleanly implements part of issue #483 (Snowflake dialect support) without interfering with existing functionality or introducing technical debt.

---

Job run | Branch: feat/snowflake-like-any-all-483

[github-actions]

Claude finished @ajitpratap0's task —— View job

---

Code Review: Snowflake LIKE ANY/ALL Implementation

Completed comprehensive review of the Snowflake LIKE ANY/ALL and ILIKE ANY/ALL pattern matching implementation.

Todo List

• Read and analyze the parser implementation changes
• Review test coverage and quality
• Check for potential bugs and edge cases
• Assess performance considerations
• Verify security implications
• Check adherence to project patterns

---

✅ Overall Assessment: APPROVED

This is a well-implemented, focused feature addition that correctly follows the project's patterns and conventions.

📋 Detailed Review

Code Quality: Excellent

The implementation in pkg/sql/parser/expressions_operators.go:113-135 is:

• Clean and readable: Clear variable naming and logical flow
• Well-documented: Excellent inline comments explaining the Snowflake syntax
• Consistent: Follows existing parser patterns for LIKE/ILIKE handling
• Properly integrated: Leverages existing parsePrimaryExpression() for tuple parsing

Implementation Details: Sound

✅ Correct operator composition: "LIKE ANY", "ILIKE ALL" etc.
✅ Proper token consumption: Consumes LIKE/ILIKE, then ANY/ALL, then expects (
✅ Reuses existing logic: Uses parsePrimaryExpression() which handles tuples correctly
✅ Standard AST structure: Creates BinaryExpression with quantified operator string
✅ NOT support: Correctly handles NOT LIKE ANY/ALL via existing notPrefix logic

Test Coverage: Comprehensive

The test file pkg/sql/parser/snowflake_like_any_all_test.go covers:

• ✅ Basic LIKE ANY and LIKE ALL patterns
• ✅ ILIKE ANY variant (case-insensitive)
• ✅ NOT LIKE ANY and NOT ILIKE ALL negations
• ✅ Proper Snowflake dialect restriction
• ✅ Integration with high-level gosqlx.ParseWithDialect() API

Suggestion: Consider adding edge case tests:

// Empty tuple test
"empty_tuple": `SELECT * FROM t WHERE name LIKE ANY ()`
// Single element tuple
"single_tuple": `SELECT * FROM t WHERE name LIKE ANY ('%test%')`

Security: No Concerns

• ✅ No new attack vectors introduced
• ✅ Reuses existing, safe tuple parsing logic
• ✅ Properly validates syntax before proceeding
• ✅ Standard error handling with location information

Performance: Optimal

• ✅ Zero overhead: Only executes when ANY/ALL tokens present
• ✅ O(1) token checks: Uses efficient isType() checks
• ✅ Memory efficient: Leverages object pooling from parsePrimaryExpression()
• ✅ No new allocations: Reuses existing AST structures

Edge Cases & Error Handling

✅ Missing parentheses: Line 123 properly expects ( after ANY/ALL
✅ Malformed tuples: Delegated to parsePrimaryExpression() which handles validation
✅ Dialect restriction: No explicit check, but ILIKE validation covers most cases

Minor Enhancement Opportunity: Consider explicit dialect checking:

// After line 117, add:
if p.dialect != "" && p.dialect != string(keywords.DialectSnowflake) {
    return nil, fmt.Errorf("LIKE %s is Snowflake-specific", quantifier)
}

Integration & Consistency

✅ Follows project patterns: Mirrors existing ANY/ALL subquery logic (lines 297-335)
✅ Consistent error handling: Uses p.expectedError() helper
✅ Proper AST generation: Creates standard BinaryExpression nodes
✅ Memory management: Delegates to pooled expressions via parsePrimaryExpression()

🎯 Recommendations

1. Ship as-is: This implementation is production-ready
2. Consider adding: Explicit Snowflake dialect validation for better error messages
3. Future enhancement: Edge case tests for empty/single-element tuples

🔄 Part of Larger Epic

This cleanly implements part of issue #483 (Snowflake dialect support) without interfering with existing functionality or introducing technical debt.

---

Job run | Branch: feat/snowflake-like-any-all-483