3.x: Upgrade bundled orafce from 4.9.2 to 4.16.13

Offen
  • Stimmt etwas nicht?
#2,174 0 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

@tuhaihe arbeitet bereits daran.

Seit 27.10.2026.

  • #2208 von @tuhaihe — offen

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
c, git, postgresql, sql
Bereich
databases

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
C
Sterne
1.4k
Forks
265
Ø Merge
3 T. 18 Std.
Gemergte PRs (30 T.)
70

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/cloudberry

Alle Issues in apache/cloudberry

Ähnliche Issues

Weitere Issues zu C

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.