fix(plpgsql-deparser): dehydrateTypeName never used the AST — CAST deparse form broke extraction, losing array bounds on renamed types

[pyramation]

Summary

dehydrateTypeName was silently broken: deparseTypeNameNode wraps the hydrated TypeName node in SELECT NULL::type and extracted the result with /SELECT\s+NULL::(.+)/ — but Deparser.deparse emits the SELECT CAST(NULL AS type) form, so the regex never matched, deparseTypeNameNode always returned null, and dehydration always fell back to typname.original.

Consequence: any consumer that renames schemas by mutating typname.typeNameNode.names in the hydrated AST got the original (or a hand-rebuilt) string back. Downstream (constructive-db transform-schemas) this corrupted DECLARE sections — _cached "old-schema".mytype[] became new_schema.mytype (array bounds dropped), producing runtime 22P02 Missing left parenthesis failures on array_fill assignment.

Fix:

 const match =
-  deparsed.match(/SELECT\s+NULL::(.+)/i);
+  deparsed.match(/SELECT\s+NULL::(.+)/i) ||
+  deparsed.match(/^SELECT\s+CAST\(NULL\s+AS\s+(.+)\)[\s;]*$/i);

With the AST path working, arrayBounds (and typemods) on the TypeName node are preserved through dehydrate → deparse.

Test added in hydrate.test.ts: hydrate DECLARE v_items "old-schema".mytype[], rename the schema in typeNameNode.names, dehydrate + deparse, assert new_schema.mytype[] keeps its brackets. Full plpgsql-deparser suite passes (100 tests).

Link to Devin session: https://app.devin.ai/sessions/eeb8deba0c04475091df703c88877302
Requested by: @pyramation

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring