|
| 1 | +# AST Translation Test Plan |
| 2 | + |
| 3 | +This document outlines a set of incremental tests for building and validating a PostgreSQL AST translation layer. The goal is to ensure ASTs parsed from older versions can be upgraded to the latest version without changing semantic meaning. |
| 4 | + |
| 5 | +## 1. Baseline Parsing |
| 6 | + |
| 7 | +1. **Parse basic queries for each version** |
| 8 | + - Verify `parseSync` and `parse` return a single statement for simple queries (`SELECT 1`, `SELECT NULL`). |
| 9 | +2. **Round-trip parsing** |
| 10 | + - Parse a query, deparse it back to SQL, and parse again. The ASTs should match after removing location data. |
| 11 | + |
| 12 | +## 2. Enum Handling |
| 13 | + |
| 14 | +1. **Integer to string conversion (PG13/14)** |
| 15 | + - Feed known enum codes to the translation layer and assert the upgraded AST uses the correct enum names. |
| 16 | +2. **Preserve string enums (PG15+)** |
| 17 | + - Ensure enums already represented as strings remain unchanged after translation. |
| 18 | + |
| 19 | +## 3. Scalar Node Changes |
| 20 | + |
| 21 | +1. **Field rename checks** |
| 22 | + - Confirm that `String.str` becomes `String.sval`, `BitString.str` becomes `BitString.bsval`, and `Float.str` becomes `Float.fval` when translating from PG13/14. |
| 23 | +2. **Boolean node introduction** |
| 24 | + - Translating `A_Const` nodes containing boolean values should yield the new `Boolean` node starting in PG15. |
| 25 | + |
| 26 | +## 4. Renamed Fields |
| 27 | + |
| 28 | +Create fixtures demonstrating renamed fields such as `relkind` → `objtype` and `tables` → `pubobjects`. Tests should confirm the new field names and that values are correctly copied. |
| 29 | + |
| 30 | +## 5. Sequential Upgrade Steps |
| 31 | + |
| 32 | +For each release boundary (13→14, 14→15, 15→16, 16→17): |
| 33 | +1. Apply the specific upgrade function to a representative AST. |
| 34 | +2. Validate that required fields are present and obsolete ones removed. |
| 35 | +3. Verify that running all steps in sequence produces the same result as any direct upgrade path (once implemented). |
| 36 | + |
| 37 | +## 6. Full Query Upgrade |
| 38 | + |
| 39 | +1. Parse a library of real-world queries using the oldest supported version. |
| 40 | +2. Upgrade the resulting ASTs to the latest version. |
| 41 | +3. Deparse the upgraded ASTs and execute them against a running PostgreSQL instance to ensure semantics are preserved. |
| 42 | + |
| 43 | +## 7. Future Regression Tests |
| 44 | + |
| 45 | +As translation functions evolve, capture edge cases that previously failed and assert they remain fixed. |
| 46 | + |
| 47 | +--- |
| 48 | + |
| 49 | +These tests build confidence incrementally: start with simple node transformations, then cover whole query upgrades. The plan emphasizes functional, deterministic checks that can run in CI. |
0 commit comments