fix: handle unnamed "any" parameters and improve npgsql query generation#32
fix: handle unnamed "any" parameters and improve npgsql query generation#32
Conversation
- Map unresolved "any" parameters to `string` type in F# generation - Replace `pkg/errors` with standard `fmt.Errorf` - Fix npgsql parameter replacement to use regex for accurate substitution - Add fallback names for unnamed parameters (e.g., `column_2`, `dollar_4`) - Add tests for parameter naming, type mapping, and query generation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: de9620184d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| case "any": | ||
| return "interface{}" | ||
| // sqlc reports unresolved expression parameters (for example | ||
| // string_to_array($1, $2)) as "any". Emit text so the generated F# | ||
| // stays usable unless the SQL adds a more specific cast. | ||
| return "string" |
There was a problem hiding this comment.
Keep unresolved
any as unknown before type reconciliation
Returning "string" for postgresType(... == "any") breaks the duplicate-parameter reconciliation path in columnsToStruct, which only treats "interface{}" as an unknown type (result.go checks field.Type == "interface{}" before unifying duplicates). For queries where the same named parameter is emitted multiple times and at least one occurrence is unresolved (any) while another has a concrete type, checkIncompatibleFieldTypes now reports a false incompatibility (for example string vs int32) and code generation fails.
Useful? React with 👍 / 👎.
stringtype in F# generationpkg/errorswith standardfmt.Errorfcolumn_2,dollar_4)