SQL*Plus und PL/SQL sind seit Jahren uneins – es gibt viele Fälle, in denen sich die Art und Weise, wie eine Aufgabe mit SQL*Plus ausgeführt wird, von der Ausführung derselben oder einer ähnlichen Aufgabe in PL/SQL unterscheidet. Außerdem sind in PL/SQL Datentypen verfügbar, die in SQL*Plus nicht verfügbar waren. Oracle Version 21c bietet eine Möglichkeit, einige der PL/SQL-Datentypen in SQL*Plus-Typdefinitionen zu verwenden, mit der Einschränkung, dass die PL/SQL-Typen nicht persistent sein werden. Was bedeutet das und wie geht man mit diesem neu gefundenen Schriftenschatz um? Lassen Sie uns weiter nachforschen und sehen, was wir finden.
Seit einiger Zeit erforderte das Erstellen bestimmter Typen sowohl in PL/SQL als auch in SQL*Plus eine Änderung der Syntax – ein Typ mit zwei Elementen in PL?SQL ist ein Datensatz, und dieselbe Typkonstruktion in SQL*Plus wird zu einem Objekttyp. Daran haben sich Entwickler gewöhnt. Wenn diese Typen jedoch PL/SQL-Typen (boolean, pls_integer, binary_integer usw.) enthalten müssen, gab es in SQL*Plus leider keine einfache Möglichkeit, diese Anforderung zu erfüllen. Bis 21c. Sehen wir uns ein Beispiel an, wie solche Typen in SQL*Plus-Typdefinitionen verwendet werden können. Nehmen wir an, als Argument wird ein Typ mit einem BOOLEAN-Datentyp in SQL*Plus benötigt. Vor 21c wäre eine Menge Codierung erforderlich, um den Datentyp BOOLEAN nachzuahmen – mit 21c können wir BOOLEAN als Typ verwenden, solange die Datenbank nicht versucht, die Daten auf der Festplatte zu speichern:
SQL> create or replace 2 type EMP_SAL_APPROVAL_FOR_PL as object 3 ( e_num number, 4 e_nme varchar2(35), 5 new_sal number, 6 mgr_approve boolean 7 ) not persistable ; 8 / Type created.
Ein solches Objekt kann zur Laufzeit mit dem BOOLEAN-Wert an eine PL/SQL-Programmeinheit übergeben werden, und Oracle weiß, dass der BOOLEAN-Wert nicht außerhalb des aktuellen Kontexts bestehen bleiben soll. Wie bereits erwähnt, ist dies nicht auf BOOLEAN-Werte beschränkt; Lassen Sie uns sowohl einen PLS_INTEGER als auch einen BINARY_INTEGER ausprobieren:
SQL> create or replace 2 type EMP_SAL_APPROVAL_FOR_PL as object 3 ( e_num number, 4 e_nme varchar2(35), 5 new_sal number, 6 mgr_approve boolean, 6 old_sal pls_integer, 7 yrly_sal binary_integer 8 ) not persistable ; 9 / Type created.
Alle Datentypen, die in SQL*Plus nicht persistiert werden können, werden aufgrund der „not persistent“-Anweisung nicht gespeichert, obwohl sie zur Laufzeit an eine PL/SQL-Einheit übergeben werden können.
Wenn Sie sich fragen, ob dies auch für die Verwendung in verschachtelten Tabellen und varrays verfügbar ist, lautet die Antwort ja:
SQL> create or replace 2 type i_array as 3 varray(40) of (binary_integer) 4 not persistable; 5 / Type created.
Leider erlaubt dies nicht die Verwendung einer %TYPE-Referenz (eine bekannte und häufig verwendete Abkürzung mit PL/SQL-Codierung, um den Typabgleich zwischen PL/SQL-Code und den verwendeten Tabellen sicherzustellen) in jedem Typ, der die Direktive „not persistent“ verwendet:
SQL> create or replace 2 type EMP_SAL_APPROVAL_FOR_PL as object 3 ( e_num emp.empno%type, 4 e_nme varchar2(35), 5 new_sal number, 6 mgr_approve boolean, 6 old_sal pls_integer, 7 yrly_sal binary_integer 8 ) not persistable ; 9 / Warning: Type created with compilation errors. SQL> SQL> show errors Errors for TYPE EMP_SAL_APPROVAL_FOR_PL LINE/COL ERROR -------- ----------------------------------------------------- 0/0 PL/SQL: Compilation unit analysis terminated 3/12 PLS-00201: identifier 'EMP.EMPNO' must be declared
Oracle hat mit der „not persistent“-Direktive einen bedeutenden Schritt gemacht, der es Programmierern ermöglicht, PL/SQL-Datentypen in SQL*Plus-Typdefinitionen zu verwenden; Dies wird höchstwahrscheinlich nur begrenzten Nutzen oder Reiz haben, wenn man weiß, dass die durch solche Konstrukte repräsentierten Daten nicht in der Datenbank gespeichert werden, aber wenn BOOLEAN-, PL:S_INTEGER- oder BINARY_INTEGER-Werte von SQL*Plus an PL/SQL-Programmeinheiten übergeben werden, ist dies möglich Eliminieren Sie Probleme mit Typkonflikten, die dadurch verursacht werden, dass solche Typen in SQL*Plus nicht vorhanden sind. Und dies ist wahrscheinlich der erste Schritt zur Erweiterung der funktionalen Kompatibilität von SQL*Plus mit PL/SQL.
