Review a SQL Server stored procedure or function during PostgreSQL-to-MSSQL migration work. Use when Codex is given an MSSQL stored-program SQL file or path and should compare it with the same-named PostgreSQL function, copy meaningful comments into the MSSQL source, and produce a Markdown report for any behavior-changing differences in control flow, data updates, filtering, transactions, return values, or side effects.
Annotate an MSSQL stored program by reusing useful comments from the matching PostgreSQL function. Identify behavior-changing gaps between the two implementations and summarize them in a separate Markdown report without modifying the PostgreSQL source or silently fixing the MSSQL code.
Accept any of these as the starting point:
.sql fileUse additional context when available:
Treat the PostgreSQL function as the comparison baseline. Try to match by object name first. If more than one PostgreSQL candidate exists, prefer the one that:
If the match is still ambiguous, stop and ask the user which PostgreSQL function is authoritative.
Edit only the MSSQL file. Never edit the PostgreSQL file. Copy or adapt comments only when the surrounding logic is substantively the same. Do not copy comments for logic that is missing or materially different in MSSQL. Place comments immediately above or alongside the corresponding MSSQL block using the prevailing SQL Server comment style. Prefer concise comments that explain intent, business meaning, boundary handling, and non-obvious update logic.
Good candidates for transferred comments include:
Do not add comments that merely restate syntax.
Ignore purely syntactic or stylistic differences. Report only differences that could change execution results, operational safety, or externally visible behavior.
Examples of reportable differences:
If a difference is uncertain, say that it is a likely gap or a potential gap and explain why.
Always update the MSSQL source file in place with comments when appropriate.
Also create a Markdown gap report in a sibling docs/ directory under the MSSQL file's folder.
Create the docs/ directory if it does not exist.
Use this naming rule for the gap report:
<mssql-object-name>_migration_gap_report.mdIf a same-folder naming conflict exists, append a short suffix such as _v2.
Follow the template in references/gap-report-template.md.
The report should include:
Write the gap report in Japanese unless the user asks otherwise.
Keep the MSSQL program executable after comment insertion. Do not reorder logic just to make comments easier to place. Do not implement the proposed fixes unless the user explicitly asks for code changes beyond comment insertion. When no behavior-changing gap is found, still create the report and state that no material difference was detected.
Compare the two implementations by logical stages:
Use table definitions only when needed to understand keys, nullability, or update semantics.
Before finishing, verify that: