3.x: Upgrade bundled orafce from 4.9.2 to 4.16.13

Ouverte
  • Quelque chose ne va pas ?
#2,174 0 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

@tuhaihe y travaille déjà.

Depuis le 27/10/2026.

  • #2208 par @tuhaihe — ouverte

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
c, git, postgresql, sql
Domaine
databases

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
C
Étoiles
1.4k
Forks
265
Merge moyen
3 j 18 h
PR mergées (30 j)
70

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/cloudberry

Toutes les issues de apache/cloudberry

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.