Reviewing Oracle To Postgres Migration
GitHubOfficialFirst committed by PrimedPaulDistributed by GitHub
- Skill
- Workflow
- Software development
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a systematic approach to managing database migrations from Oracle to PostgreSQL. It centers on a reference-based workflow that helps developers identify behavioral differences—such as empty string handling, type coercion, and pagination logic—during the planning phase and verify that these risks are addressed during the validation phase. By cross-referencing migration artifacts against known technical discrepancies, it ensures that application logic and database schemas are correctly adapted for the PostgreSQL environment.
What it does
- Provides a risk assessment workflow for planning database migrations.
- Offers a validation workflow to confirm migration work meets PostgreSQL requirements.
- Maintains a library of known behavioral differences between Oracle and PostgreSQL.
- Guides users through documenting risks and recommended fix patterns.
- Ensures integration tests cover critical Oracle-to-PostgreSQL behavioral gaps.
- Supports decision-making for handling specific database object migrations.
When to use it
- When planning the migration of database objects like procedures, triggers, or views.
- When reviewing completed migration artifacts to ensure all behavioral risks are mitigated.
- When validating that integration tests adequately cover Oracle-to-PostgreSQL differences.
- When you need a structured checklist to gate the success of a database migration task.
Advantages
- Reduces the risk of runtime errors caused by subtle database behavioral differences.
- Standardizes the migration process across different database objects.
- Provides clear, actionable guidance for common migration pitfalls.
- Facilitates thorough testing by highlighting specific scenarios that require validation.
Usage examples
- “I am planning to migrate a set of Oracle stored procedures to PostgreSQL. How should I start?”
- The agent will guide you through the Risk Assessment workflow, helping you list affected objects and screen them against the reference index to document necessary changes.
- “I have finished migrating a query that uses ROWNUM. How do I validate this?”
- The agent will initiate the Validation workflow, prompting you to map the artifact, check it against the ROWNUM-specific reference, and verify that your integration tests cover the new LIMIT/OFFSET logic.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/github/reviewing-oracle-to-postgres-migration/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip reviewing-oracle-to-postgres-migration.zip -d .agents/skills
Documentation by PrimedPaul
Oracle-to-PostgreSQL Database Migration
Surfaces migration risks and validates migration work against known Oracle/PostgreSQL behavioral differences documented in the references/ folder.
When to use
Planning — Before starting migration work on a procedure, trigger, query, or refcursor client. Identify which reference insights apply so risks are addressed up front.
Validating — After migration work is done, confirm every applicable insight was addressed and integration tests cover the new PostgreSQL semantics.
Workflow
Determine the task type:
Planning a migration? Follow the risk assessment workflow. Validating completed work? Follow the validation workflow.
Risk assessment workflow (planning)
Risk Assessment:
- [ ] Step 1: Identify the migration scope
- [ ] Step 2: Screen each insight for applicability
- [ ] Step 3: Document risks and recommended actionsStep 1: Identify the migration scope
List the affected database objects (procedures, triggers, queries, views) and the application code that calls them.
Step 2: Screen each insight for applicability
Review the reference index in references/REFERENCE.md. For each entry, determine whether the migration scope contains patterns affected by that insight. Read the full reference file only when the insight is potentially relevant.
Step 3: Document risks and recommended actions
For each applicable insight, note the specific risk and the recommended fix pattern from the reference file. Flag any insight that requires a design decision (e.g., whether to preserve Oracle empty-string-as-NULL semantics or adopt PostgreSQL behavior).
Validation workflow (post-migration)
Validation:
- [ ] Step 1: Map the migration artifact
- [ ] Step 2: Cross-check applicable insights
- [ ] Step 3: Verify integration test coverage
- [ ] Step 4: Gate the resultStep 1: Map the migration artifact
Identify the migrated object and summarize the change set.
Step 2: Cross-check applicable insights
For each reference in references/REFERENCE.md, confirm the behavior or test requirement is acknowledged and addressed in the migration work.
Step 3: Verify integration test coverage
Confirm tests exercise both the happy path and the failure scenarios highlighted in applicable insights (exceptions, sorting, UNION ALL behavior/performance risks, refcursor consumption, concurrent transactions, timestamps, materialized-view freshness, etc.).
Step 4: Gate the result
Return a checklist asserting each applicable insight was addressed, migration scripts run, and integration tests pass.
Files
- ATTRIBUTION.mdAdded by AutoGineer913 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md3.1 KiB
- references/REFERENCE.md2.8 KiB
- references/empty-strings-handling.md2.0 KiB
- references/no-data-found-exceptions.md2.6 KiB
- references/oracle-nvl-decode-functions.md2.4 KiB
- references/oracle-parentheses-from-clause.md4.8 KiB
- references/oracle-rownum-pagination.md2.1 KiB
- references/oracle-sysdate-sequences-dual.md3.2 KiB
- references/oracle-to-postgres-sorting.md2.7 KiB
- references/oracle-to-postgres-timestamp-timezone.md8.4 KiB
- references/oracle-to-postgres-to-char-numeric.md4.2 KiB
- references/oracle-to-postgres-type-coercion.md4.9 KiB
- references/postgres-concurrent-transactions.md9.4 KiB
- references/postgres-materialized-view-refresh.md1.4 KiB
- references/postgres-refcursor-handling.md5.7 KiB
- references/postgres-union-all-planner.md1.6 KiB
references/oracle-parentheses-from-clause.md
Oracle to PostgreSQL: Parentheses in FROM Clause
Contents
Problem
Root Cause
Solution Pattern
Examples
Migration Checklist
Common Locations
Application Code Examples
Error Messages to Watch For
Testing Recommendations
Problem
Oracle allows optional parentheses around table names in the FROM clause:
-- Oracle: Both are valid
SELECT * FROM (TABLE_NAME) WHERE id = 1;
SELECT * FROM TABLE_NAME WHERE id = 1;PostgreSQL does not allow extra parentheses around a single table name in the FROM clause without it being a derived table or subquery. Attempting to use this pattern results in:
Npgsql.PostgresException: 42601: syntax error at or near ")"Root Cause
Oracle: Treats
FROM(TABLE_NAME)as equivalent toFROM TABLE_NAMEPostgreSQL: Parentheses in the FROM clause are only valid for:
Subqueries:
FROM (SELECT * FROM table)Explicit table references that are part of join syntax
Common Table Expressions (CTEs)
Without a valid SELECT or join context, PostgreSQL raises a syntax error
Solution Pattern
Remove the unnecessary parentheses around the table name:
-- Oracle (problematic in PostgreSQL)
SELECT col1, col2
FROM (TABLE_NAME)
WHERE id = 1;
-- PostgreSQL (correct)
SELECT col1, col2
FROM TABLE_NAME
WHERE id = 1;Examples
Example 1: Simple Table Reference
-- Oracle
SELECT employee_id, employee_name
FROM (EMPLOYEES)
WHERE department_id = 10;
-- PostgreSQL (fixed)
SELECT employee_id, employee_name
FROM EMPLOYEES
WHERE department_id = 10;Example 2: Join with Parentheses
-- Oracle (problematic)
SELECT e.employee_id, d.department_name
FROM (EMPLOYEES) e
JOIN (DEPARTMENTS) d ON e.department_id = d.department_id;
-- PostgreSQL (fixed)
SELECT e.employee_id, d.department_name
FROM EMPLOYEES e
JOIN DEPARTMENTS d ON e.department_id = d.department_id;Example 3: Valid Subquery Parentheses (Works in Both)
-- Both Oracle and PostgreSQL
SELECT *
FROM (SELECT employee_id, employee_name FROM EMPLOYEES WHERE department_id = 10) sub;Migration Checklist
When fixing this issue, verify:
Identify all problematic FROM clauses:
Search for
FROM (pattern in SQLVerify the opening parenthesis is immediately after
FROMfollowed by a table nameConfirm it's not a subquery (no SELECT keyword inside)
Distinguish valid parentheses:
✅
FROM (SELECT ...)- Valid subquery✅
FROM (table_namefollowed by a join - Check if JOIN keyword follows❌
FROM (TABLE_NAME)- Invalid, remove parentheses
Apply the fix:
Remove the parentheses around the table name
Keep parentheses for legitimate subqueries
Test thoroughly:
Execute the query in PostgreSQL
Verify result set matches original Oracle query
Include in integration tests
Common Locations
Search for FROM ( in:
✅ Stored procedures and functions (DDL scripts)
✅ Application data access layers (DAL classes)
✅ Dynamic SQL builders
✅ Reporting queries
✅ Views and materialized views
✅ Complex queries with multiple joins
Application Code Examples
VB.NET
' Before (Oracle)
StrSQL = "SELECT employee_id, NAME " _
& "FROM (EMPLOYEES) e " _
& "WHERE e.department_id = 10"
' After (PostgreSQL)
StrSQL = "SELECT employee_id, NAME " _
& "FROM EMPLOYEES e " _
& "WHERE e.department_id = 10"C
// Before (Oracle)
var sql = "SELECT id, name FROM (USERS) WHERE status = @status";
// After (PostgreSQL)
var sql = "SELECT id, name FROM USERS WHERE status = @status";Error Messages to Watch For
Npgsql.PostgresException: 42601: syntax error at or near ")"
ERROR: syntax error at or near ")"
LINE 1: SELECT * FROM (TABLE_NAME) WHERE ...
^Testing Recommendations
Syntax Verification: Parse all migrated queries to ensure they run without syntax errors
[Fact] public void GetEmployees_ExecutesWithoutSyntaxError() { // Should not throw PostgresException with error code 42601 var employees = dal.GetEmployees(departmentId: 10); Assert.NotEmpty(employees); }Result Comparison: Verify that result sets are identical before and after migration
Regex-based Search: Use pattern
FROM\s*\(\s*[A-Za-z_][A-Za-z0-9_]*\s*\)to identify candidates
Related Files
Reference: oracle-to-postgres-type-coercion.md - Other syntax differences
PostgreSQL Documentation: SELECT Statement
Migration Notes
This is a straightforward syntactic fix with no semantic implications
No data conversion required
Safe to apply automated find-and-replace, but manually verify complex queries
Update integration tests to exercise the migrated queries
Requirements and compatibility
Written for: GitHub Copilot
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- First committed by
PrimedPaul
- Publisher
- GitHub (Official)
- Distributed by
- GitHub
- Source
- github/awesome-copilot · skills/reviewing-oracle-to-postgres-migration · commit 797337f
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Contributors
- PrimedPaul
AutoGineer is not affiliated with or endorsed by PrimedPaul or GitHub.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download reviewing-oracle-to-postgres-migration.zip