mirror of
https://github.com/github/awesome-copilot.git
synced 2026-08-21 16:36:51 +00:00
f7e8aaa2d8
* Enhance Oracle-to-PostgreSQL migration skills and documentation
- Update migration agent guidelines to prioritize extension tool usage for code migration.
- Refine migration phases with detailed steps for pre-migration review and schema migration.
- Add new reviewing skill references for PostgreSQL materialized view refresh and UNION ALL planner risks.
- Ensure consistency in collation handling and testing strategies across skills.
* - Review migration phases to ensure correct order of execution
- Add exit criteria to each migration phase
- Remove invocation of `ms-ossdata.vscode-pgsql` extension due to dependency on VSCode
- Update README.md to reflect changes in migration phases and exit criteria
- Update broken reference to custom agent in plugin.json
* Enhance downstream migration skills and following custom agent improvements
- Added new skill for migrating .NET data access code from Oracle to PostgreSQL.
- Updated README to include new migration skill.
- Improved existing skills with clearer file naming conventions and migration actions.
- Added reference documents for handling Oracle-specific functions and pagination.
- Created detailed guides for NVL, DECODE, ROWNUM, SYSDATE, and DUAL replacements.
* Clarify PostgreSQL schema immutability and stored procedure migration risks
* Update target schema path in migration documentation for clarity
* fix(skills): clarify Phase 3-only scope for Oracle test skills
Both Oracle test skills were ambiguously worded in ways that could
cause a model to invoke them during Phase 6 (PostgreSQL test migration)
instead of using them exclusively in Phase 3.
Key changes:
- Rewrite descriptions to explicitly state Phase 3-only usage and
warn against invoking during Phase 6
- Replace "scaffold for Oracle first" with "Oracle only" to remove
the false implication of a second PostgreSQL scaffolding step
- Replace "Tests validate behavior consistency when running against
Oracle or PostgreSQL" with clear Oracle-only framing
- Rename "DB-agnostic assertions" → "Assertion portability" and
explain the why (survive Phase 6 migration without rewrites)
- Fix datetime bullet in integration tests skill to use generic
Oracle column precision language instead of PostgreSQL type syntax
- Name Oracle NuGet package explicitly (Oracle.ManagedDataAccess.Core)
* feat(oracle-to-postgres): gate Phase 1 on DDL presence; add DDL scan to Phase 2 risk analysis
- Phase 1 success criteria now requires Oracle DDL artifacts to be
confirmed present at the recorded location before proceeding.
If missing, the agent stops and prompts the user to provide them.
- Phase 2 risk analysis now explicitly scans DDL/Oracle/{ProjectName}/
as supplemental context, summarising procedure complexity indicators
(dynamic SQL, DBMS_* / UTL_* references, autonomous transactions,
pipelined functions, BULK COLLECT/FORALL, REF CURSOR, TYPE bodies)
rather than ingesting DDL files wholesale. This ensures schema-level
migration risk is captured even when it isn't visible in application
code alone.
* - Merge in latest 'main' changes
- Update custom agent plugin (eg resolve conflict and add new skill)
- Validate skills
- Run build
* chore(plugin.json): update version to 1.1.0
* feat(oracle-to-postgres): update version to 1.1.0 for migration expert plugin
* fix: add INOUT to ignore-words-list for PostgreSQL migration
---------
Co-authored-by: TCPrimedPaul <paul.delannoy@tc.gc.ca>
80 lines
2.4 KiB
Markdown
80 lines
2.4 KiB
Markdown
# Oracle to PostgreSQL: NVL, DECODE, and Null-Handling Functions
|
|
|
|
## Problem
|
|
|
|
Oracle provides several functions — `NVL`, `NVL2`, `DECODE` — that have no direct equivalents in standard SQL but are commonly used in Oracle stored procedures and inline SQL. PostgreSQL uses standard SQL alternatives: `COALESCE`, `NULLIF`, and `CASE` expressions.
|
|
|
|
## Behavior Comparison
|
|
|
|
### NVL
|
|
|
|
**Oracle:** `NVL(expr, replacement)` — returns `replacement` if `expr` is `NULL`, otherwise `expr`.
|
|
|
|
**PostgreSQL:** Use `COALESCE(expr, replacement)` — semantically identical for two arguments.
|
|
|
|
```sql
|
|
-- Oracle
|
|
NVL(column_name, 'default')
|
|
|
|
-- PostgreSQL
|
|
COALESCE(column_name, 'default')
|
|
```
|
|
|
|
### NVL2
|
|
|
|
**Oracle:** `NVL2(expr, not_null_val, null_val)` — returns `not_null_val` if `expr` IS NOT NULL, `null_val` if NULL.
|
|
|
|
**PostgreSQL:** No direct equivalent — use `CASE`:
|
|
|
|
```sql
|
|
-- Oracle
|
|
NVL2(column_name, 'has value', 'no value')
|
|
|
|
-- PostgreSQL
|
|
CASE WHEN column_name IS NOT NULL THEN 'has value' ELSE 'no value' END
|
|
```
|
|
|
|
### DECODE
|
|
|
|
**Oracle:** `DECODE(expr, search1, result1, search2, result2, ..., default)` — equality-based switch.
|
|
|
|
**PostgreSQL:** No `DECODE` function — use `CASE WHEN`:
|
|
|
|
```sql
|
|
-- Oracle
|
|
DECODE(status, 1, 'Active', 2, 'Inactive', 'Unknown')
|
|
|
|
-- PostgreSQL
|
|
CASE status
|
|
WHEN 1 THEN 'Active'
|
|
WHEN 2 THEN 'Inactive'
|
|
ELSE 'Unknown'
|
|
END
|
|
```
|
|
|
|
Note: `DECODE` in Oracle treats two `NULL` values as equal (unlike `=`). If any search value is `NULL`, use `IS NULL` in the `CASE` equivalent:
|
|
|
|
```sql
|
|
-- Oracle: DECODE treats NULL = NULL
|
|
DECODE(col, NULL, 'empty', col)
|
|
|
|
-- PostgreSQL
|
|
CASE WHEN col IS NULL THEN 'empty' ELSE col END
|
|
```
|
|
|
|
## Migration Actions
|
|
|
|
### 1. Stored Procedures
|
|
|
|
Apply the direct substitutions above. Pay special attention to:
|
|
- `NVL` on numeric expressions — `COALESCE` is type-sensitive in PostgreSQL; ensure both arguments are the same type or cast explicitly.
|
|
- `DECODE` with `NULL` search values — replace with `IS NULL` guard in the `CASE` expression.
|
|
|
|
### 2. Application Code (inline SQL strings)
|
|
|
|
Search C# string literals and query builders for `NVL(`, `NVL2(`, and `DECODE(`. Apply the same substitutions.
|
|
|
|
### 3. Tests
|
|
|
|
Write test cases that exercise `NULL` inputs specifically — the Oracle → PostgreSQL translation of `NVL`/`COALESCE` is straightforward, but edge cases around NULL equality in `DECODE` → `CASE` are a common source of silent behavioral differences.
|