Reserved words handling + Support for data store selection

[jacknagz]

Summary

• Refactor reserved words implementation to follow official Snowflake documentation precisely
• Add support for quoting reserved words inside function calls (e.g., COUNT(DISTINCT account))
• Implement smart filtering to avoid inappropriately quoting SQL keywords
• Add comprehensive test coverage including real-world VPC Flow logs scenarios

Test plan

• All existing tests pass (105 passed, 4 skipped)
• New comprehensive test suite covers success and error cases
• Real-world AWS VPC Flow logs query example tested and working
• Function call detection prevents quoting function names
• CASE WHEN expressions work correctly
• Forbidden keyword validation works as expected
• Linting passes

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ panther-bot-automation
❌ jacknagz
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[darwayne]

Looks mostly good just had a question

[jacknagz]

Resolves #78

[jacknagz]

Ok, this is looking ready.

Summary of Reserved Word Testing
I've successfully executed 10 queries testing various Snowflake reserved words and baselining behaviors on the panther_audit logs.

Test Results:

Query 1 - Initially failed with CURRENT_DATE (correctly caught as reserved), then succeeded when using explicit date
Query 2 - Successfully used DATE, TYPE, GROUP BY, and ORDER BY
Query 3 - Successfully used TIMESTAMP functions and HOUR
Query 4 - Failed when trying to use ROWS in window functions (syntax error)
Query 5 - Successfully used ORDER BY with complex expressions
Query 6 - Successfully used TIME functions with EXTRACT and CASE
Query 7 - Successfully used CTEs (WITH clause) and nested queries
Query 8 - Successfully used SELECT with complex field references
Query 9 - Successfully used TABLE references in subqueries
Query 10 - Successfully combined multiple reserved words in a complex query

Key Findings:

The reserved word check is working - It correctly caught CURRENT_DATE and prevented its use
Most reserved words can be used as aliases - Words like USER, DATE, TYPE, COUNT, etc. work fine as column aliases
Context matters - Some reserved words like ROWS cause syntax errors in specific contexts (window functions)
The check appears to focus on specific problematic reserved words rather than all Snowflake reserved words

[jacknagz]

🚀 Additional Updates Since Initial PR

This PR has been significantly enhanced with additional improvements beyond the original data lake query management functionality:

📊 New Data Lake Query Management Tools

• list_data_lake_queries() - Comprehensive query monitoring with filtering by status, date ranges, content search, and pagination
• cancel_data_lake_query() - Resource management tool to terminate long-running queries and prevent system overload

🏗️ Enhanced Type Safety & Modern Annotations

• Migrated from Optional[T] to modern T | None syntax following fastmcp best practices
• Added QueryStatus(str, Enum) for type-safe status filtering
• Implemented proper MCP tool annotations:
  • readOnlyHint: true for monitoring operations
  • destructiveHint: true for query cancellation
• Added regex patterns for ISO 8601 datetime validation

🔍 Comprehensive Test Coverage

• Added 9 new test functions covering success, error, and edge cases
• Tests for both user-issued and API token-issued queries
• Validation of filtering, pagination, and error handling
• All tests passing with improved type safety

📋 GraphQL Schema Integration

• Added LIST_DATA_LAKE_QUERIES query with complete field selection
• Added CANCEL_DATA_LAKE_QUERY mutation for resource management
• Proper handling of user vs API token issuer information

⚡ Key Benefits

• Performance Monitoring: Identify and cancel resource-intensive queries
• System Health: Prevent data lake overload during peak usage
• Operational Visibility: Track query history, timing, and ownership
• Type Safety: Enum-based validation prevents runtime errors
• User Experience: Clear error messages and comprehensive filtering

🎯 Common Use Cases

# Find running queries that need attention
list_data_lake_queries(status=[QueryStatus.RUNNING])

# Monitor recent query activity
list_data_lake_queries(started_at_after="2024-01-01T00:00:00.000Z")

# Cancel problematic queries
cancel_data_lake_query("long-running-query-id")

The implementation follows all fastmcp best practices and provides essential tools for managing data lake performance and preventing system overload. 🎉