Skip to content

Conversation

@pyramation
Copy link
Collaborator

fix(plpgsql-deparser): expand PLpgSQL_row fields when refname is '(unnamed row)'

Summary

Fixes a bug where SELECT INTO and EXECUTE ... INTO statements targeting variables would output INTO (unnamed row) instead of the actual variable names like INTO v_rowcount.

When PostgreSQL parses a SELECT INTO statement, it creates a PLpgSQL_row datum with refname set to "(unnamed row)". The actual variable names are stored in the fields array with varno references that point to the real variables in the datums array.

This fix modifies deparseDatumName() to:

  1. Accept an optional context parameter to access the datums array
  2. Check if PLpgSQL_row.refname is "(unnamed row)"
  3. If so, expand the fields array by resolving varno references to get actual variable names
  4. Return the comma-separated list of variable names

All callers of deparseDatumName() have been updated to pass the context parameter.

Review & Testing Checklist for Human

  • Verify all callers updated: Confirm that all 9 call sites of deparseDatumName() now pass the context parameter (lines 772, 813, 844, 1060, 1088, 1110, 1227, 1307, 1331)
  • Check recursive call safety: The recursive call at line 1331 intentionally omits context to prevent infinite loops - verify this doesn't cause issues with nested row structures
  • Test with constructive-db: After publishing, regenerate the constructive module and verify the app_limits_inc function no longer has INTO (unnamed row) syntax errors

Test Plan

  1. Merge and publish new plpgsql-deparser version
  2. Update constructive-db to use new version
  3. Run pnpm run generate:metaschema-rls to regenerate the constructive module
  4. Verify generated functions in application/constructive/deploy/schemas/constructive_limits_private/procedures/ have correct INTO clauses
  5. Run pnpm test -- rls.modular.test.ts to verify RLS tests pass

Notes

…named row)'

When SELECT INTO targets multiple variables, PostgreSQL creates a PLpgSQL_row
datum with refname '(unnamed row)' and stores the actual variable names in
the fields array with varno references.

This fix modifies deparseDatumName() to:
1. Accept an optional context parameter to access the datums array
2. Check if PLpgSQL_row.refname is '(unnamed row)'
3. If so, expand the fields array by resolving varno references to get
   actual variable names
4. Return the comma-separated list of variable names

All callers of deparseDatumName() have been updated to pass the context
parameter where available.

This fixes the issue where generated PL/pgSQL functions contained
'INTO (unnamed row)' instead of the actual variable names like
'INTO v_rowcount'.
@devin-ai-integration
Copy link
Contributor

🤖 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 and CI monitoring

@pyramation pyramation merged commit b87555b into main Jan 6, 2026
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants