mirror of
https://github.com/github/awesome-copilot.git
synced 2026-08-20 16:06:57 +00:00
Paul Delannoy
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>
49 lines
3.1 KiB
Markdown
49 lines
3.1 KiB
Markdown
---
|
|
name: migrating-oracle-to-postgres-stored-procedures
|
|
description: 'Migrates Oracle PL/SQL stored procedures to PostgreSQL PL/pgSQL. Translates Oracle-specific syntax, preserves method signatures and type-anchored parameters, leverages orafce where appropriate, and applies explicit collation mapping (`COLLATE "C"` only when appropriate, locale collations when required). Use when converting Oracle stored procedures or functions to PostgreSQL equivalents during a database migration.'
|
|
---
|
|
|
|
# Migrating Stored Procedures from Oracle to PostgreSQL
|
|
|
|
Translate Oracle PL/SQL stored procedures and functions to PostgreSQL PL/pgSQL equivalents.
|
|
|
|
## Workflow
|
|
|
|
```
|
|
Progress:
|
|
- [ ] Step 1: Read the Oracle source procedure
|
|
- [ ] Step 2: Translate to PostgreSQL PL/pgSQL
|
|
- [ ] Step 3: Write the migrated procedure to Postgres output directory
|
|
```
|
|
|
|
**Step 1: Read the Oracle source procedure**
|
|
|
|
Read the Oracle stored procedure from `.github/oracle-to-postgres-migration/DDL/Oracle/Procedures and Functions/`. Consult the Oracle table/view definitions at `.github/oracle-to-postgres-migration/DDL/Oracle/Tables and Views/` for type resolution.
|
|
|
|
**Step 2: Translate to PostgreSQL PL/pgSQL**
|
|
|
|
Apply these translation rules:
|
|
|
|
- Translate all Oracle-specific syntax to PostgreSQL equivalents.
|
|
- Preserve original functionality and control flow logic.
|
|
- Keep type-anchored input parameters (e.g., `PARAM_NAME IN table_name.column_name%TYPE`).
|
|
- Use explicit types (`NUMERIC`, `VARCHAR`, `INTEGER`) for output parameters passed to other procedures — do not type-anchor these.
|
|
- Do not alter method signatures.
|
|
- Do not prefix object names with schema names unless already present in the Oracle source.
|
|
- Leave exception handling and rollback logic unchanged.
|
|
- Do not generate `COMMENT` or `GRANT` statements.
|
|
- Apply collation intentionally when ordering text:
|
|
- Use `COLLATE "C"` only when Oracle-compatible binary ordering is required and no other sort order is specified.
|
|
- If Oracle used explicit linguistic sorting (for example `NLS_SORT = French`), map to an explicit PostgreSQL locale collation instead of `"C"`.
|
|
- Use `SELECT collname, collprovider, collcollate, collctype FROM pg_collation ORDER BY collname;` to discover collations in the target environment.
|
|
- Treat `UNION ALL` as a review checkpoint. Validate plan quality per branch and restructure if combined-branch planning causes regressions (for example, unexpected sequential scans on large tables).
|
|
- Leverage the `orafce` extension when it improves clarity or fidelity.
|
|
|
|
Consult the PostgreSQL table/view definitions at `.github/oracle-to-postgres-migration/DDL/Postgres/{ProjectName}/Tables and Views/` for target schema details.
|
|
|
|
**Step 3: Write the migrated procedure to Postgres output directory**
|
|
|
|
Place each migrated procedure in its own file under `.github/oracle-to-postgres-migration/DDL/Postgres/{ProjectName}/Procedures and Functions/{PACKAGE_NAME_IF_APPLICABLE}/`. One procedure per file.
|
|
|
|
> `{ProjectName}` is the project's assembly/folder name with spaces normalized to `-` (e.g. `MyApp.DataAccess`). This matches the path used by the agent and other migration skills.
|