Identifies Oracle-to-PostgreSQL migration risks by cross-referencing code against known behavioral differences (empty strings, refcursors, type coercion, sorting/collations, UNION ALL planner risks, materialized-view refresh requirements, timestamps, concurrent transactions, etc.). Use when planning

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 1. Planning — Before starting migration work on a procedure, trigger, query, or refcursor client. Identify which reference insights apply so risks are addressed up front. 2. 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) Step 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](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) Step 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](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.

reviewing-oracle-to-postgres-migration