feat(plpgsql-deparser): enable heterogeneous deparse for AST-based transformations #262
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
feat(plpgsql-deparser): enable heterogeneous deparse for AST-based transformations
Summary
This PR enables AST-based transformations (e.g., schema renaming) to be properly reflected in deparsed PL/pgSQL function bodies. Previously, modifications to AST nodes in hydrated expressions were ignored because
dehydrateQuery()returned the original string fields instead of deparsing the modified AST.Key changes:
deparseExprNode()helper that wraps expression AST nodes in a SELECT statement, deparses, and strips the prefixdehydrateQuery()forsql-exprkind to always prefer deparsing the AST nodedehydrateQuery()forassignkind to prefer deparsingtargetExpr/valueExprAST nodes when availablehydrate-demo.test.tsto demonstrate proper AST-based modifications (instead of string field modifications)query.target,query.value, andquery.originalare now ignored if AST nodes exist. Users should modify AST nodes directly for transformations.Review & Testing Checklist for Human
query.originalwould work. Now AST modifications are preferred. Confirm this behavioral change is intentional and acceptable for downstream users.normalizeForComparison()function is defined but appears unused in the final implementation - should it be removed?::type→CAST(... AS type), multi-lineORconditions). Verify these don't break downstream consumers.v_user "schema".users) use stringtypnamefields, not AST nodes, so they won't be transformed. Confirm this limitation is documented/acceptable.Recommended test plan:
pnpm testinpackages/plpgsql-deparserto verify all 26 tests passNotes