feat(parser): Snowflake COPY INTO / PUT / GET / LIST stubs (#483)

[ajitpratap0]

Summary

Adds top-level Snowflake stage-operation statements as parse-only stubs.

What now parses

• `COPY INTO FROM FILE_FORMAT = (...)` — both directions (table↔stage)
• `PUT file:// @`
• `GET @ file://`
• `LIST @` (and `LS`)
• `REMOVE @/`

Implementation

• New `parseSnowflakeStageStatement` in `parser.go`. Consumes the leading kind token (+ INTO for COPY), then walks to `;` / EOF tracking balanced parens so embedded `FILE_FORMAT = (...)` blocks round-trip.
• Dispatched from both the identifier and keyword branches of the statement dispatcher, since LIST tokenizes as a keyword while COPY/PUT/GET/REMOVE tokenize as identifiers.
• Stubs reuse the `DescribeStatement` placeholder, same approach as `USE` (feat(parser): Snowflake USE/DESCRIBE top-level statements (#483) #491) and `CREATE STAGE` (feat(parser): Snowflake CREATE STAGE/STREAM/TASK/PIPE stubs (#483) #498). Dedicated AST types are follow-up work.

Test plan

• `TestSnowflakeStageOps`: 7 shapes covering all kinds, both COPY directions, named/inline file formats, ON_ERROR option
• `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 8, 2026 5:09pm

[github-actions]

Claude finished @ajitpratap0's task —— View job

---

PR Review: Snowflake COPY INTO / PUT / GET / LIST stubs

Todo List

• Read repository guidelines (CLAUDE.md)
• Analyze parser.go changes
• Review test file implementation
• Evaluate code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Review security concerns
• Evaluate test coverage
• Provide comprehensive feedback

Analysis

Implementation Overview:
The PR adds a parseSnowflakeStageStatement function in pkg/sql/parser/parser.go that handles Snowflake stage operations (COPY INTO, PUT, GET, LIST/LS, REMOVE) as parse-only stubs. The implementation reuses the existing DescribeStatement AST node as a placeholder, similar to the approach used for other dialect-specific features.

Key Changes:

1. Parser.go (lines 770-811): New function that consumes tokens until semicolon/EOF while tracking balanced parentheses
2. Statement dispatcher updates: Added calls to the new function in both keyword and identifier branches (lines 716 & 740)
3. Test coverage: 7 test cases covering all statement types and various parameter combinations

Code Quality Assessment

✅ Strengths

1. Consistent with Repository Patterns

   • Follows the established pattern of using DescribeStatement as a placeholder for stub implementations
   • Properly uses object pools (ast.GetDescribeStatement())
   • Dialect-specific parsing only when p.dialect == string(keywords.DialectSnowflake)

2. Robust Token Consumption

   • Correctly tracks balanced parentheses to handle complex FILE_FORMAT = (...) blocks
   • Proper termination conditions (semicolon or EOF)
   • Handles both keyword and identifier token dispatch paths

3. Good Documentation

   • Clear function documentation with examples of all supported statement types
   • Explains the stub approach and mentions follow-up work for dedicated AST types

⚠️ Areas for Improvement

1. Unused Variable (Line 782-783)

   startPos := p.currentLocation()
   _ = startPos  // Unused variable

   Recommendation: Remove both lines or use startPos for error reporting context.

2. Potential Parentheses Tracking Issue
   The current logic tracks () parentheses but doesn't handle other bracket types like [] or {} that might appear in Snowflake syntax.

   // Current: only handles ()
   if t == models.TokenTypeLParen {
       depth++
   } else if t == models.TokenTypeRParen {
       depth--
   }

3. Error Handling Enhancement
   Missing validation for unbalanced parentheses. If depth becomes negative or remains positive at EOF, the parser should report an error.

Security & Performance

✅ Security - No Concerns

• No user input validation needed since this is parse-only
• No dynamic SQL generation or execution
• Proper bounds checking via existing tokenizer infrastructure

✅ Performance - Well Optimized

• Uses object pooling (ast.GetDescribeStatement()) consistent with project performance patterns
• O(n) token consumption with minimal memory allocation
• Leverages existing tokenizer infrastructure efficiently

Test Coverage

✅ Comprehensive Coverage

The test file snowflake_stage_ops_test.go covers:

• ✅ All 5 statement types (COPY INTO both directions, PUT, GET, LIST, REMOVE)
• ✅ Complex FILE_FORMAT parameters with nested parentheses
• ✅ Various Snowflake-specific syntax elements (@stage, file://, ON_ERROR options)
• ✅ Both named and inline format specifications

Minor Test Enhancement Suggestions:

1. Add test for LS alias (mentioned in code but not tested)
2. Test edge cases like unbalanced parentheses (should this error or be handled gracefully?)
3. Consider negative test cases (invalid syntax)

Minor Issues Found

1. Line 783: Remove unused startPos variable
2. Parentheses tracking: Consider whether other bracket types need handling
3. Error reporting: Add validation for unbalanced parentheses

Overall Assessment

✅ High Quality Implementation - This PR follows GoSQLX best practices excellently:

• Consistent with repository patterns and coding standards
• Proper object pool usage for performance
• Comprehensive test coverage
• Good documentation
• Follows the established stub approach for incremental dialect support

The implementation is production-ready and aligns perfectly with the project's architecture. The identified issues are minor and don't impact functionality.

Recommendation

APPROVE - The code is well-implemented and ready for merge. Consider addressing the minor unused variable cleanup in a follow-up commit.

---

Job Run

[github-actions]

Claude finished @ajitpratap0's task —— View job

---

PR Review: Snowflake COPY INTO / PUT / GET / LIST stubs

Todo List

• Read repository guidelines (CLAUDE.md)
• Analyze parser.go changes
• Review test file implementation
• Evaluate code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Review security concerns
• Evaluate test coverage
• Provide comprehensive feedback

Analysis

Implementation Overview:
The PR adds a parseSnowflakeStageStatement function in pkg/sql/parser/parser.go that handles Snowflake stage operations (COPY INTO, PUT, GET, LIST/LS, REMOVE) as parse-only stubs. The implementation reuses the existing DescribeStatement AST node as a placeholder, similar to the approach used for other dialect-specific features.

Key Changes:

1. Parser.go (lines 770-811): New function that consumes tokens until semicolon/EOF while tracking balanced parentheses
2. Statement dispatcher updates: Added calls to the new function in both keyword and identifier branches (lines 716 & 740)
3. Test coverage: 7 test cases covering all statement types and various parameter combinations

Code Quality Assessment

✅ Strengths

1. Consistent with Repository Patterns

   • Follows the established pattern of using DescribeStatement as a placeholder for stub implementations
   • Properly uses object pools (ast.GetDescribeStatement())
   • Dialect-specific parsing only when p.dialect == string(keywords.DialectSnowflake)

2. Robust Token Consumption

   • Correctly tracks balanced parentheses to handle complex FILE_FORMAT = (...) blocks
   • Proper termination conditions (semicolon or EOF)
   • Handles both keyword and identifier token dispatch paths

3. Good Documentation

   • Clear function documentation with examples of all supported statement types
   • Explains the stub approach and mentions follow-up work for dedicated AST types

⚠️ Areas for Improvement

1. Unused Variable (Line 782-783)

   startPos := p.currentLocation()
   _ = startPos  // Unused variable

   Recommendation: Remove both lines or use startPos for error reporting context.

2. Potential Parentheses Tracking Issue
   The current logic tracks () parentheses but doesn't handle other bracket types like [] or {} that might appear in Snowflake syntax.

   // Current: only handles ()
   if t == models.TokenTypeLParen {
       depth++
   } else if t == models.TokenTypeRParen {
       depth--
   }

3. Error Handling Enhancement
   Missing validation for unbalanced parentheses. If depth becomes negative or remains positive at EOF, the parser should report an error.

Security & Performance

✅ Security - No Concerns

• No user input validation needed since this is parse-only
• No dynamic SQL generation or execution
• Proper bounds checking via existing tokenizer infrastructure

✅ Performance - Well Optimized

• Uses object pooling (ast.GetDescribeStatement()) consistent with project performance patterns
• O(n) token consumption with minimal memory allocation
• Leverages existing tokenizer infrastructure efficiently

Test Coverage

✅ Comprehensive Coverage

The test file snowflake_stage_ops_test.go covers:

• ✅ All 5 statement types (COPY INTO both directions, PUT, GET, LIST, REMOVE)
• ✅ Complex FILE_FORMAT parameters with nested parentheses
• ✅ Various Snowflake-specific syntax elements (@stage, file://, ON_ERROR options)
• ✅ Both named and inline format specifications

Minor Test Enhancement Suggestions:

1. Add test for LS alias (mentioned in code but not tested)
2. Test edge cases like unbalanced parentheses (should this error or be handled gracefully?)
3. Consider negative test cases (invalid syntax)

Minor Issues Found

1. Line 783: Remove unused startPos variable
2. Parentheses tracking: Consider whether other bracket types need handling
3. Error reporting: Add validation for unbalanced parentheses

Overall Assessment

✅ High Quality Implementation - This PR follows GoSQLX best practices excellently:

• Consistent with repository patterns and coding standards
• Proper object pool usage for performance
• Comprehensive test coverage
• Good documentation
• Follows the established stub approach for incremental dialect support

The implementation is production-ready and aligns perfectly with the project's architecture. The identified issues are minor and don't impact functionality.

Recommendation

APPROVE - The code is well-implemented and ready for merge. Consider addressing the minor unused variable cleanup in a follow-up commit.

---

Job Run

[github-actions]

Claude finished @ajitpratap0's task —— View job

---

PR Review: Snowflake COPY INTO / PUT / GET / LIST stubs

Todo List

• Read repository guidelines (CLAUDE.md)
• Analyze parser.go changes
• Review test file implementation
• Evaluate code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Review security concerns
• Evaluate test coverage
• Provide comprehensive feedback

Analysis

Implementation Overview:
The PR adds a parseSnowflakeStageStatement function in pkg/sql/parser/parser.go:770-809 that handles Snowflake stage operations (COPY INTO, PUT, GET, LIST/LS, REMOVE) as parse-only stubs. The implementation reuses the existing DescribeStatement AST node as a placeholder, similar to the approach used for other dialect-specific features.

Key Changes:

1. Parser.go (lines 770-809): New function that consumes tokens until semicolon/EOF while tracking balanced parentheses
2. Statement dispatcher updates: Added calls to the new function in both keyword and identifier branches (lines 716 & 740)
3. Test coverage: 8 test cases covering all statement types and various parameter combinations

Code Quality Assessment

✅ Strengths

1. Consistent with Repository Patterns

   • Follows the established pattern of using DescribeStatement as a placeholder for stub implementations
   • Properly uses object pools (ast.GetDescribeStatement())
   • Dialect-specific parsing only when p.dialect == string(keywords.DialectSnowflake)

2. Robust Token Consumption

   • Correctly tracks balanced parentheses to handle complex FILE_FORMAT = (...) blocks
   • Proper termination conditions (semicolon or EOF)
   • Handles both keyword and identifier token dispatch paths

3. Good Documentation

   • Clear function documentation with examples of all supported statement types
   • Explains the stub approach and mentions follow-up work for dedicated AST types

⚠️ Minor Improvement Opportunities

1. Error Handling Enhancement
   Missing validation for unbalanced parentheses. If depth becomes negative, the parser should report an error:

   } else if t == models.TokenTypeRParen {
       depth--
       if depth < 0 {
           return nil, p.expectedError("balanced parentheses")
       }
   }

2. Potential Bracket Types
   The current logic tracks () parentheses but doesn't handle other bracket types like [] or {} that might appear in Snowflake syntax. However, this is likely fine for the current use cases.

Security & Performance

✅ Security - No Concerns

• No user input validation needed since this is parse-only
• No dynamic SQL generation or execution
• Proper bounds checking via existing tokenizer infrastructure

✅ Performance - Well Optimized

• Uses object pooling (ast.GetDescribeStatement()) consistent with project performance patterns
• O(n) token consumption with minimal memory allocation
• Leverages existing tokenizer infrastructure efficiently

Test Coverage

✅ Comprehensive Coverage

The test file snowflake_stage_ops_test.go covers:

• ✅ All 5 statement types (COPY INTO both directions, PUT, GET, LIST, REMOVE)
• ✅ Complex FILE_FORMAT parameters with nested parentheses
• ✅ Various Snowflake-specific syntax elements (@stage, file://, ON_ERROR options)
• ✅ Both named and inline format specifications
• ✅ LS alias for LIST statement

Overall Assessment

✅ High Quality Implementation - This PR follows GoSQLX best practices excellently:

• Consistent with repository patterns and coding standards
• Proper object pool usage for performance
• Comprehensive test coverage
• Good documentation
• Follows the established stub approach for incremental dialect support

The implementation is production-ready and aligns perfectly with the project's architecture. The only potential enhancement is adding validation for unbalanced parentheses, but this is minor.

Recommendation

APPROVE - The code is well-implemented, thoroughly tested, and ready for merge. Consider adding parentheses balance validation in a future enhancement.

---

Job Run

[github-actions]

Claude finished @ajitpratap0's task —— View job

---

PR Review: Snowflake COPY INTO / PUT / GET / LIST stubs

Todo List

• Read repository guidelines (CLAUDE.md)
• Analyze parser.go changes
• Review test file implementation
• Evaluate code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Review security concerns
• Evaluate test coverage
• Provide comprehensive feedback

Analysis

Implementation Overview:
The PR adds a parseSnowflakeStageStatement function in pkg/sql/parser/parser.go:770-809 that handles Snowflake stage operations (COPY INTO, PUT, GET, LIST/LS, REMOVE) as parse-only stubs. The implementation reuses the existing DescribeStatement AST node as a placeholder, similar to the approach used for other dialect-specific features.

Key Changes:

1. Parser.go (lines 770-809): New function that consumes tokens until semicolon/EOF while tracking balanced parentheses
2. Statement dispatcher updates: Added calls to the new function in both keyword and identifier branches (lines 716 & 740)
3. Test coverage: 8 test cases covering all statement types and various parameter combinations

Code Quality Assessment

✅ Strengths

1. Consistent with Repository Patterns

   • Follows the established pattern of using DescribeStatement as a placeholder for stub implementations
   • Properly uses object pools (ast.GetDescribeStatement())
   • Dialect-specific parsing only when p.dialect == string(keywords.DialectSnowflake)

2. Robust Token Consumption

   • Correctly tracks balanced parentheses to handle complex FILE_FORMAT = (...) blocks
   • Proper termination conditions (semicolon or EOF)
   • Handles both keyword and identifier token dispatch paths

3. Good Documentation

   • Clear function documentation with examples of all supported statement types
   • Explains the stub approach and mentions follow-up work for dedicated AST types

⚠️ Minor Improvement Opportunities

1. Error Handling Enhancement
   Missing validation for unbalanced parentheses. If depth becomes negative, the parser should report an error:

   } else if t == models.TokenTypeRParen {
       depth--
       if depth < 0 {
           return nil, p.expectedError("balanced parentheses")
       }
   }

2. Potential Bracket Types
   The current logic tracks () parentheses but doesn't handle other bracket types like [] or {} that might appear in Snowflake syntax. However, this is likely fine for the current use cases.

Security & Performance

✅ Security - No Concerns

• No user input validation needed since this is parse-only
• No dynamic SQL generation or execution
• Proper bounds checking via existing tokenizer infrastructure

✅ Performance - Well Optimized

• Uses object pooling (ast.GetDescribeStatement()) consistent with project performance patterns
• O(n) token consumption with minimal memory allocation
• Leverages existing tokenizer infrastructure efficiently

Test Coverage

✅ Comprehensive Coverage

The test file snowflake_stage_ops_test.go covers:

• ✅ All 5 statement types (COPY INTO both directions, PUT, GET, LIST, REMOVE)
• ✅ Complex FILE_FORMAT parameters with nested parentheses
• ✅ Various Snowflake-specific syntax elements (@stage, file://, ON_ERROR options)
• ✅ Both named and inline format specifications
• ✅ LS alias for LIST statement

Overall Assessment

✅ High Quality Implementation - This PR follows GoSQLX best practices excellently:

• Consistent with repository patterns and coding standards
• Proper object pool usage for performance
• Comprehensive test coverage
• Good documentation
• Follows the established stub approach for incremental dialect support

The implementation is production-ready and aligns perfectly with the project's architecture. The only potential enhancement is adding validation for unbalanced parentheses, but this is minor.

Recommendation

APPROVE - The code is well-implemented, thoroughly tested, and ready for merge. Consider adding parentheses balance validation in a future enhancement.

---

Job Run