3.x: Upgrade bundled orafce from 4.9.2 to 4.16.13

Aperta
  • Qualcosa non va?
#2,174 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@tuhaihe ci sta già lavorando.

Dal 27/10/2026.

  • #2208 di @tuhaihe — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c, git, postgresql, sql
Ambito
databases

Direzione di ricerca

Start with gpcontrib/orafce/README.gp and the current regression schedule in gpcontrib/orafce; identify which of the 21 SQL tests can run in MPP before expanding coverage. Then compare the local patches with upstream tag VERSION_4_16_13 and preserve applicable changes. Done means the update chain, fresh install, upgrade and pg_upgrade paths pass, licensing checks stay green, and release notes describe user-visible changes.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

The bundled gpcontrib/orafce is 4.9.2 (META.json:5; orafce.control default_version = '4.9', imported 2024-07). Propose upgrading it to 4.16.13 — the current release of the upstream series that supports PostgreSQL 16 — as part of 3.0.

orafce is the Oracle-compatibility layer many migration workloads depend on, so refreshing it is user-visible content for a major release, not just dependency hygiene.

Current state

  • 4.9.2 is roughly seven minor releases and 2+ years behind upstream (4.10 → 4.16.x). 4.16.13 is currently packaged for PG16 by PGDG and distributions.
  • The module is imported as a git subtree of orafce/orafce (workflow documented in gpcontrib/orafce/README.gp), so the upgrade is a git subtree pull to tag VERSION_4_16_13, with local patches applied explicitly afterwards.
  • PG16 compatibility today is fine: there are 9 #if PG_VERSION_NUM >= 160000 guards in the code, and CI runs gpcontrib/orafce:installcheck as part of the required ic-gpcontrib check. This issue is about refreshing content, not fixing a build.
  • Test coverage is thin: Makefile:76,92 runs REGRESS = orafce plus --schedule=parallel_schedule, but the schedule only lists init, dbms_pipe_session_A, dbms_pipe_session_B — that is 4 of the 21 SQL test files (~19%). The dbms_alert tests are commented out as MPP-unsuitable.
  • Local delta that must survive the upgrade:
    • regexp_not_like() added to orafce--4.8--4.9.sql and orafce--4.9.sql (7bda69676d5);
    • MPP test adaptations (gp_distributed_by, gp_partition_by, nlssort) and rebranding (b64d461e37c);
    • locale handling change in others.c (4af1cf5a09b).

Why this belongs in 3.0

  • A major release is the natural window to refresh a bundled dependency; doing it now avoids turning this into a multi-year jump.
  • orafce is user-facing: accumulated upstream fixes and compatibility improvements can be summarized as a concrete 3.0 highlight in the release notes.
  • It keeps future refreshes cheap — the next one can target a handful of minor releases instead of seven.

Work items

  • Prerequisite: expand orafce regression coverage — move as many of the 21 test files into the schedule as can run single-node/MPP, keeping dbms_alert skipped with an explicit reason. Without this, behavior changes from the upgrade are invisible.
  • git subtree pull orafce/orafce at tag VERSION_4_16_13 (per README.gp).
  • Re-apply the local delta: regexp_not_like() (check whether upstream 4.16 has adopted it — drop the patch if so), MPP test adaptations, others.c locale handling, rebranding.
  • Ship the full upgrade chain from 4.9 to 4.16.13 (orafce--4.9--4.10.sql … orafce--4.16.13.sql) plus the new base install script; bump orafce.control default_version and META.json.
  • Verify the extension update path: CREATE EXTENSION orafce VERSION '4.9'; ALTER EXTENSION orafce UPDATE;, and a pg_upgrade from a 2.x cluster (pg_upgrade's update_extensions.sql emits ALTER EXTENSION orafce UPDATE).
  • Check licensing: orafce is 0BSD (COPYRIGHT.orafce), registered under LICENSE:542 + licenses/LICENSE-orafce.txt; confirm copyright/NOTICE text is still accurate after the update and RAT stays green.
  • Run the required ic-gpcontrib check plus broader ICW; prepare a short "user-visible changes" section for the 3.0 release notes.

Acceptance criteria

  • \dx orafce reports 4.16.13; fresh install, update from 4.9, and a 2.x → 3.0 pg_upgrade all succeed.
  • Existing orafce behavior is unchanged except for documented upstream fixes/features; the expanded test suite passes.
  • regexp_not_like() and the other Cloudberry-specific behavior remain available.
  • License/NOTICE and RAT checks stay green; CI ic-gpcontrib is green.
  • A user-visible changes section is ready for the 3.0 release notes.

Risks

  • Compatibility-layer semantics changes may alter results for Oracle-migration workloads; needs release-note attention.
  • Local SQL patches complicate the subtree merge and the upgrade-script chain.
  • Expanding tests in an MPP environment may require per-test expected-output adaptation — scope the prerequisite before starting the merge.

References

Lingua principale
C
Stelle
1.4k
Fork
265
Merge medio
3g 18h
PR unite (30g)
70

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/cloudberry

Tutte le issue di apache/cloudberry

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.