How do I install the Migrating Oracle To Postgres Stored Procedures skill?

Run npx skillmds@latest add gabrielmoreira/migrating-oracle-to-postgres-stored-procedures in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Migrating Oracle To Postgres Stored Procedures safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Migrating Oracle To Postgres Stored Procedures?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Migrating Oracle To Postgres Stored Procedures free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Migrating Oracle To Postgres Stored Procedures?

gabrielmoreira (@gabrielmoreira) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Migrating Oracle To Postgres Stored Procedures by gabrielmoreira

Name: Migrating Oracle To Postgres Stored Procedures
Rating: 4.5 (4 reviews)
Author: gabrielmoreira

Migrating Oracle To Postgres Stored Procedures

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.

gabrielmoreira Updated Sep 9, 2026 17 repo stars

File contents

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.

---name: migrating-oracle-to-postgres-stored-proceduresdescription: 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.

Frequently asked questions