mirror of
https://github.com/github/awesome-copilot.git
synced 2026-08-23 09:26:52 +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>
76 lines
2.1 KiB
Markdown
76 lines
2.1 KiB
Markdown
# Oracle to PostgreSQL: ROWNUM Pagination vs LIMIT/OFFSET
|
||
|
||
## Problem
|
||
|
||
Oracle uses `ROWNUM` pseudo-column for pagination and row-limiting. PostgreSQL uses standard `LIMIT` / `OFFSET` syntax. `ROWNUM` is also fundamentally different in *when* it is assigned, which affects filtering behavior.
|
||
|
||
## Behavior Comparison
|
||
|
||
**Oracle:**
|
||
- `ROWNUM` is assigned before `ORDER BY` — filtering with `ROWNUM` on an unordered result set is non-deterministic
|
||
- Common pattern to get "top N ordered rows" requires a subquery:
|
||
```sql
|
||
SELECT * FROM (SELECT * FROM t ORDER BY col) WHERE ROWNUM <= 10
|
||
```
|
||
- `ROWNUM BETWEEN n AND m` requires a double-wrapped subquery
|
||
|
||
**PostgreSQL:**
|
||
- `LIMIT n` restricts result rows after `ORDER BY` is applied — straightforward and deterministic
|
||
- `OFFSET n` skips rows; combine with `LIMIT` for pagination
|
||
- No `ROWNUM` pseudo-column exists
|
||
|
||
## Code Example
|
||
|
||
```sql
|
||
-- Oracle: top 10 rows by date
|
||
SELECT * FROM (
|
||
SELECT * FROM orders ORDER BY created_at DESC
|
||
) WHERE ROWNUM <= 10;
|
||
|
||
-- PostgreSQL equivalent
|
||
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10;
|
||
|
||
-- Oracle: rows 11–20 (keyset pagination via ROWNUM)
|
||
SELECT * FROM (
|
||
SELECT t.*, ROWNUM rn FROM (
|
||
SELECT * FROM orders ORDER BY created_at DESC
|
||
) t WHERE ROWNUM <= 20
|
||
) WHERE rn > 10;
|
||
|
||
-- PostgreSQL equivalent
|
||
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10 OFFSET 10;
|
||
```
|
||
|
||
## Migration Actions
|
||
|
||
### 1. Stored Procedures
|
||
|
||
Replace all `ROWNUM`-based limiting patterns with `LIMIT`/`OFFSET`:
|
||
|
||
```sql
|
||
-- Oracle
|
||
WHERE ROWNUM = 1
|
||
WHERE ROWNUM <= :n
|
||
|
||
-- PostgreSQL
|
||
LIMIT 1
|
||
LIMIT :n -- note: use $n parameter style in PL/pgSQL
|
||
```
|
||
|
||
For subquery wrapping patterns:
|
||
```sql
|
||
-- Oracle
|
||
SELECT * FROM (SELECT ... ORDER BY col) WHERE ROWNUM <= :n
|
||
|
||
-- PostgreSQL
|
||
SELECT ... ORDER BY col LIMIT :n
|
||
```
|
||
|
||
### 2. Application Code (inline SQL strings)
|
||
|
||
Search for `ROWNUM` in C# string literals, `StringBuilder`, and query-builder methods. Apply the same replacement patterns above.
|
||
|
||
### 3. Tests
|
||
|
||
Ensure integration tests validate that result set sizes are correct and that ordering is preserved (i.e., the correct *n* rows are returned, not just any *n* rows).
|