Hoist DECLAREs via sqlglot tokenizer instead of regex

[batikankarakan]

Summary

• Replaces the regex-based DECLARE hoister in pkg/pipeline/hooks.go with a sqlglot-driven implementation: tokenize with the dialect-aware tokenizer, track paren + BEGIN..END depth to find top-level ; positions, slice the original source by those positions, and classify each slice with parse_one(). sqlglot never regenerates user SQL — statement text is sliced verbatim, so casing, comments, escapes and dialect-specific syntax (e.g. array<STRING>) survive byte-for-byte.
• WrapHooks / wrapHookQueriesList now take a DeclareHoister interface implemented by SQLParser, plumbed through the HookWrapperMaterializer* structs at every call site in cmd/run.go and cmd/render.go. The parser is initialized unconditionally in run.go so the hoister is always available.
• DECLAREs nested inside BEGIN..END or stored-procedure bodies are correctly left in place; ; inside string literals no longer splits; on parse failure the input passes through unchanged.

Test plan

• make format clean
• make test clean (incl. pkg/pipeline + pkg/sqlparser)
• New TestSqlParser_HoistDeclares subtests verify byte-identical preservation, BEGIN..END exemption, string-literal safety, and array<STRING> casing survival
• New pythonsrc/parser/main_test.py cases mirror the same invariants on the Python side

🤖 Generated with Claude Code

[greptile-apps]

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
pythonsrc/parser/main.py:558-562
**`CASE...END` leaks through `begin_end_depth` tracking**

`TokenType.END` is emitted for *both* `CASE WHEN … END` expressions and `BEGIN … END` blocks — the tokenizer has no context to distinguish them. Inside a `BEGIN … END` body, a `CASE` expression's `END` will decrement `begin_end_depth` to 0 prematurely, causing the semicolons that follow (including any `DECLARE y INT64;`) to be treated as top-level. Those DECLAREs are then incorrectly hoisted out of the block.

Concrete example: `"SET x=1;\nBEGIN\n  SELECT CASE WHEN x>0 THEN 'a' ELSE 'b' END;\n  DECLARE y INT64;\nEND;"` — the `DECLARE y INT64` would be extracted and placed at the script's top, breaking stored-procedure semantics.

The same applies to `END IF`, `END WHILE`, `END LOOP` in dialects that emit individual `END` tokens for each construct. A `case_depth` counter (incremented on `TokenType.CASE`, decremented on `TokenType.END` before `begin_end_depth`) is needed to disambiguate.

### Issue 2 of 3
pythonsrc/parser/main.py:558-559
**`BEGIN TRANSACTION` inflates `begin_end_depth` without a matching `END`**

`BEGIN TRANSACTION;` produces `TokenType.BEGIN`, incrementing `begin_end_depth` to 1. `COMMIT TRANSACTION;` and `ROLLBACK TRANSACTION;` produce no `TokenType.END`, so depth never returns to 0. Every semicolon after `BEGIN TRANSACTION;` is treated as nested and excluded from `positions`.

In the common case where all DECLAREs precede the transaction block this is accidentally correct (the whole transaction body becomes one non-DECLARE slice). However, any script where `BEGIN TRANSACTION` appears before a top-level DECLARE that still needs hoisting — or where the rejoined output must produce well-formed statements — will silently get incorrect slicing. The PR test suite does not cover this pattern; the old `BEGIN TRANSACTION` test case in `TestWrapHooks_HoistsDeclares` was removed and not ported to the Python test suite.

### Issue 3 of 3
cmd/render.go:256-267
**Parser started but `Start()` called again on each invocation**

If `sqlparser.NewSQLParser(false)` succeeds but `sp.Start()` fails, `defer sp.Close()` is still registered and will run when the action function exits — which is correct. However, `sp.Start()` is called again inside `HoistDeclares` (and `HoistDeclaresList`) for every invocation, because those methods call `s.Start()` unconditionally. If `Start()` is not fully idempotent this double-start could cause unexpected behaviour. The pattern in `run.go` passes the parser only after a successful start (via a goroutine), so the two initialization styles are inconsistent. Worth confirming `Start()` is a no-op when already running.

_{Reviews (1): Last reviewed commit: "Hoist DECLARE statements via sqlglot tok..." | Re-trigger Greptile}

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
pkg/sqlparser/rustffi/src/compat.rs:1059-1074
**`BEGIN TRANSACTION` inflates `begin_end_depth` without a matching decrement**

`BEGIN TRANSACTION;` emits `TokenType::Begin`, incrementing `begin_end_depth` to 1, but `COMMIT TRANSACTION;` and `ROLLBACK TRANSACTION;` emit no `TokenType::End`, so the depth never returns to 0. Every semicolon that follows is then treated as nested and excluded from `positions`. In the common case (DECLAREs precede the transaction block) this is accidentally correct, but any script where a top-level statement or DECLARE appears after a `COMMIT TRANSACTION;` without a matching `END` will silently have those statements merged into the transaction slice, making them invisible to the hoisting classifier.

_{Reviews (2): Last reviewed commit: "ci: invalidate rust cache on rustffi/src..." | Re-trigger Greptile}

[greptile-apps]

Want your agent to iterate on Greptile's feedback? Try greploops.