Une pluie de nouveautés !
Balayons rapidement les nouveautés d'Oracle 23c (la Long Term Release qui succède à la 19c). Elles ont été recensées par Tim Hall, d'Oracle-Base (articles de Tim Hall sur Oracle 23c) :
Oracle frappe fort et prend de l'avance sur PostgreSQL ?
Pas vraiment, non. C'est même tout le contraire. D'abord, certaines de ces nouveautés ne sont pas entièrement abouties au niveau de l'implémentation dixit Tim Hall, spécialement les domaines. Surtout, TOUTES ces nouveautés d'Oracle 23c sont déjà présentes dans PostgreSQL, parfois depuis dix et même vingt ans. Les rares "nouveautés" n'en sont pas, elles sont introduites pour compenser tant bien mal de très mauvais choix conceptuels historiques qui compliquent la vie des développeurs.
Le rôle prédéfini DB_DEVELOPER_ROLE a par exemple surpris Tim Hall mais c'est sans doute parce qu'il ne connaît qu'Oracle. Pour un DBA Oracle, l'introduction de ce rôle est étonnante car c'est exactement le contraire de ce qu'Oracle recommandait auparavant. La tendance depuis la 10g était plutôt de supprimer ou limiter les rôles prédéfinis. Pour un DBA PostgreSQL, cette nouveauté est bien plus compréhensible. L'introduction de ce rôle contrebalance en effet l'existence de privilèges "système" avec Oracle. Avec ce SGBD, il faut en effet recevoir le droit de créer des tables ou des procédures en général (?!?) au lieu d'avoir le droit de créer dans quelque chose ou de faire usage de quelque chose
En dehors des quelques attributs comme "login", tout est privilège objet pour PostgreSQL, ce qui est bien plus logique et permet de gérer en amont, facilement et dynamiquement la sécurité. Oracle s'est enfin rendu compte de l'inutilité de son ensemble de privilèges système, un mécanisme complexe qui n'apporte rien au niveau de la sécurité des données.
Les concepteurs de la 23c tentent enfin de rectifier le tir sans pouvoir aller jusqu'au bout de la démarche afin de ne pas remettre en cause la compatibilité ascendante. Octroyer le rôle DB_DEVELOPER_ROLE est en gros équivalent à un "grant create on database X to Y;" avec PostgreSQL. "En gros" car les DBA Oracle savent bien que recevoir un privilège via un rôle n'est PAS l'équivalent de recevoir un privilège directement, notamment en PL/SQL. De croustillants dialogues de sourds entre DBA Oracle et développeurs modernes sont en perspective ("Tu m'as dit que tu m'avais donné tous les droits pour créer ce que je voulais mais ça marche pas !")
Certaines autres nouveautés comme la syntaxe directe de jointure pour les update sont des extensions propriétaires de PostgreSQL, hors standard. Il y a certes parfois une petite chose en plus (e.g create user if not exists pas disponible avec PostgreSQL...) mais le coeur d'Oracle reste fondamentalement obsolète sur de nombreux aspects qu'ils auront bien du mal à combler :
Conclusion
La 23c pourrait (presque) s'appeler la 23p avec p comme PostgreSQL tant l'effort porte sur le retard accumulé par Oracle depuis des années autour de fonctionnalités utiles et méme essentielles pour les développeurs, notamment le support complet de JSON.
C'est sans doute trop peu et trop tard. Les mises à jour majeures ne se font pas en claquant des doigts et les cycles sont longs. Un éditeur dont le produit est compatible avec Oracle devra très longtemps composer avec l'absence de ces fonctionnalités en 19c. Il sera sans doute d'ailleurs sur nombre d'aspects plus difficile d'être compatible Oracle 19c et Oracle 23c que PostgreSQL 10 et Oracle 23c !
Quitte à changer pour une plateforme de développement au goût du jour, autant préférer l'original à la copie et adopter un SGBD nativement plus moderne et extensible. Un très vieux SGBD, même relooké, ne sera jamais PostgreSQL.
Les carences critiques d'Oracle autour des schémas et au niveau ACID (Atomicity Consistency Isolation Durability) avec un seul niveau d'isolation couvert et encore, uniquement pour le DML (insert/update/delete/merge) perdurent et perdureront. Nul doute que les concepteurs de ce SGBD changeraient cela s'ils le pouvaient mais c'est bien plus difficile que d'ajouter une clause "if not exists" à la commande "create table".