feat(parser): Snowflake CREATE STAGE/STREAM/TASK/PIPE stubs (#483)

[ajitpratap0]

Summary

Extends the Snowflake CREATE dispatcher to parse (as stubs) object types beyond TABLE / VIEW / INDEX.

What now parses

• `CREATE STAGE`, `CREATE [OR REPLACE] PIPE`, `CREATE STREAM`, `CREATE TASK`
• `CREATE FILE FORMAT` (two-token kind)
• `CREATE WAREHOUSE`, `CREATE DATABASE`, `CREATE SCHEMA`
• `CREATE ROLE`, `CREATE SEQUENCE`, `CREATE FUNCTION`, `CREATE PROCEDURE`
• With `IF NOT EXISTS` and `OR REPLACE`

Implementation

Parse-only stubs: the dispatcher consumes the object-kind keyword, optional `IF NOT EXISTS`, the qualified name, then the rest of the statement body until `;` / EOF, tracking balanced parens so embedded expressions round-trip. The result is a `DescribeStatement` placeholder with `TableName = "CREATE "` — same approach used for `USE` in #491. This unblocks the entire Snowflake DDL class in the QA corpus without designing new AST nodes; dedicated types are follow-up work.

Test plan

• `TestSnowflakeCreateObjects`: 10 shapes covering all object kinds, two-token `FILE FORMAT`, `OR REPLACE`, `IF NOT EXISTS`, inline `AS COPY INTO ...` bodies
• `go test -race ./pkg/sql/parser/ ./pkg/gosqlx/` green

Out of scope

• AST modeling for the object bodies
• Semantic interpretation of WAREHOUSE sizing, schedule strings, task DAGs, etc.

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 2:34pm

[github-actions]

Claude finished @ajitpratap0's task —— View job

---

Code Review Complete ✅

I've thoroughly analyzed this PR that extends Snowflake CREATE statement parsing support. Here's my comprehensive review:

Todo List

• Read and analyze the modified files
• Review implementation approach and design decisions
• Examine test coverage and quality
• Check for potential bugs and security issues
• Assess performance considerations
• Provide comprehensive feedback and recommendations

---

Code Quality & Best Practices ⭐

Excellent implementation that follows established project patterns:

• ✅ Consistent with existing codebase: Uses the same stub approach as the USE statement mentioned in feat(parser): Snowflake USE/DESCRIBE top-level statements (#483) #491
• ✅ Follows project conventions: Proper error handling, consistent naming, and adheres to existing parser architecture
• ✅ Clean separation of concerns: DDL parsing logic is well-contained within the parseCreateStatement() function
• ✅ Proper dialect handling: Correctly scoped to Snowflake dialect only (p.dialect == string(keywords.DialectSnowflake))

Implementation Analysis 🔍

Strengths:

1. Smart token consumption: The balanced parentheses tracking (depth counter) ensures embedded expressions with semicolons don't prematurely terminate parsing
2. Comprehensive object coverage: Handles all major Snowflake DDL object types (STAGE, STREAM, TASK, PIPE, etc.)
3. Special case handling: Correctly handles two-token keywords like FILE FORMAT
4. Modifier support: Properly processes IF NOT EXISTS and OR REPLACE clauses
5. Graceful fallback: Uses DescribeStatement as a sensible placeholder approach

Design Decision Validation:

• Using DescribeStatement with TableName = "CREATE <KIND> <name>" is pragmatic for parse-only stubs
• Defers full AST modeling to future work, which is appropriate given the scope
• Maintains parser robustness while unblocking Snowflake DDL parsing

Test Coverage Assessment 📊

Strong test coverage with good variety:

• ✅ Comprehensive scenarios: 10 test cases covering all major object types
• ✅ Modifier testing: Tests both OR REPLACE and IF NOT EXISTS
• ✅ Complex statements: Includes realistic DDL with embedded syntax (e.g., AS COPY INTO..., USING CRON...)
• ✅ Two-token keywords: Validates FILE FORMAT handling
• ✅ Qualified names: Tests schema-qualified object names

Suggestion for improvement:
Consider adding edge cases like:

"nested_parentheses": `CREATE TASK complex_task AS INSERT INTO t (SELECT col FROM (SELECT * FROM nested))`,
"empty_body": `CREATE STAGE simple_stage`,

Performance Considerations ⚡

Efficient implementation:

• ✅ Minimal overhead: Only active for Snowflake dialect
• ✅ Single-pass parsing: No backtracking or re-parsing required
• ✅ Object pooling ready: Uses ast.GetDescribeStatement() which integrates with the project's pool system

No performance concerns - this is a lightweight parse-only implementation.

Security Analysis 🔒

No security issues identified:

• ✅ No SQL injection vectors: Parse-only approach doesn't execute or interpret DDL bodies
• ✅ Safe string handling: Uses standard Go string operations without unsafe operations
• ✅ Bounded parsing: Balanced parentheses tracking prevents infinite loops
• ✅ No external dependencies: Self-contained within existing parser infrastructure

Potential Issues & Recommendations 🔧

Minor considerations:

1. Error handling coverage: The parser gracefully handles malformed DDL by consuming tokens until semicolon/EOF. Consider whether more specific error messages would be helpful for debugging malformed Snowflake DDL.

2. Future extensibility: The current stub approach is excellent for the immediate goal. When full AST modeling is implemented, ensure the transition path maintains backward compatibility.

Code at /home/runner/work/GoSQLX/GoSQLX/pkg/sql/parser/ddl.go:105-150 is well-structured and maintainable.

Overall Assessment 🎯

This is a high-quality implementation that:

• Achieves its stated goals effectively
• Follows established project patterns
• Has excellent test coverage
• Introduces no security or performance risks
• Is well-documented and maintainable

The stub approach is appropriate for unblocking Snowflake DDL parsing while deferring complex AST modeling to future work. The implementation is robust and production-ready.

Recommendation: ✅ Approve - This PR is ready for merge.

---

Job Run