reviewing-oracle-to-postgres-migration

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Oracle-to-PostgreSQL Database Migration

Oracle到PostgreSQL数据库迁移

Surfaces migration risks and validates migration work against known Oracle/PostgreSQL behavioral differences documented in the

references/

folder.

根据

references/

文件夹中记录的Oracle与PostgreSQL已知行为差异，识别迁移风险并验证迁移工作的有效性。

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.

规划阶段 — 在开始存储过程、触发器、查询或refcursor客户端的迁移工作之前。确定哪些参考要点适用，以便提前应对风险。
验证阶段 — 迁移工作完成后，确认所有适用的参考要点均已处理，且集成测试覆盖了新的PostgreSQL语义。

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 actions

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. 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).

Risk Assessment:
- [ ] Step 1: Identify the migration scope
- [ ] Step 2: Screen each insight for applicability
- [ ] Step 3: Document risks and recommended actions

步骤1：确定迁移范围

列出受影响的数据库对象（存储过程、触发器、查询、视图）以及调用它们的应用程序代码。

步骤2：筛选每个参考要点的适用性

查看references/REFERENCE.md中的参考索引。对于每个条目，判断迁移范围是否包含受该要点影响的模式。仅当该要点可能相关时，才阅读完整的参考文件。

步骤3：记录风险与建议措施

对于每个适用的参考要点，记录参考文件中提到的具体风险和建议的修复模式。标记任何需要做出设计决策的要点（例如，是保留Oracle将空字符串视为NULL的语义，还是采用PostgreSQL的行为）。

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 result

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, 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, refcursor consumption, concurrent transactions, timestamps, etc.).

Step 4: Gate the result

Return a checklist asserting each applicable insight was addressed, migration scripts run, and integration tests pass.

Validation:
- [ ] Step 1: Map the migration artifact
- [ ] Step 2: Cross-check applicable insights
- [ ] Step 3: Verify integration test coverage
- [ ] Step 4: Gate the result

步骤1：梳理迁移成果

确定已迁移的对象并总结变更集。

步骤2：交叉核对适用的参考要点

对于references/REFERENCE.md中的每个参考内容，确认迁移工作中已考虑并处理了相关行为或测试要求。

步骤3：验证集成测试覆盖范围

确认测试既覆盖了正常流程，也覆盖了适用参考要点中强调的失败场景（异常、排序、refcursor消费、并发事务、时间戳等）。

步骤4：结果准入

返回一份检查清单，确认所有适用的参考要点均已处理、迁移脚本已运行且集成测试通过。