Many people enjoyed reading my last blog post “10 Oracle SQL features you probably didn’t know”. So I decided to spice it up a little more and do something similar for plsql.
I hope you like that one too.
With our further ado, let’s get started with the list.
10. The first Oracle version to feature plsql was Oracle DB version 6 (1988)
And no. Steven Feuerstein did NOT invent it.
At that time PLSQL did not have stored procedures nor did it have proper exception handling. But it already had embedded SQL.
I learned that from the great Lewis Cunningham. One of the godfathers of development with SQL and PLSQL.
Stored Procedures were added in Oracle 7 (1992). 7.3 was the version when I started to work with an Oracle Database. At that point plsql was in version 2.x. However there never was a version 3. Plsql versioning jumped to 8 when Oracle DB version 8 was introduced and plsql versioning was aligned with the db versions. So there are no plsql versions 3-7. But honestly? Nobody cares anymore that plsql does have its own versioning.
9. labels do not need to match
We can use <<labels>> in plsql. Mostly to increase readability of code. This is especially useful for loop constructs, but it also works for normal begin..end blocks.
begin
<<mainloop>>
loop
<<check_some>>
begin
<<dummyloop>>
for r in (select * from dual) loop
-- do nothing
null;
end loop dummyloop;
end check_some;
exit when 1=1;
end loop mainloop;
end;
/
As we can see there are several <<labels>>. And the usage of those labels at the “end” helps to distinguish which code part we are looking at [1].
But this is only as good as the programmer is!
Unfortunatly this works too:
begin
<<mainloop>>
loop
<<check_some>>
begin
<<dummyloop>>
for r in (select * from dual) loop
-- do nothing
null;
end loop mainloop;
end check_sum;
exit when 1=1;
end loop dummyloop;
end;
/
Here I mixed up the labels from the loops. And the “end check_sum” does not match the label at the beginning of the block. In fact the “label” at the end can be anything that is not a reserved word.
It runs identical to the previous code (still doing nothing). But it is way more confusing for the “future me” that has to maintain this mess.
8. pragma SERIALLY_REUSABLE
During the lifetime of a session, the package state (package variables, open cursors, etc.) are held in the UGA (user global area). Subsequent calls in the same session to the same package profit from that by not needing to reinitialize the package state.
The pragma SERIALLY_REUSABLE is able to change this behaviour.
serially_reusable packages
After the work unit (server call) of a SERIALLY_REUSABLE package completes, Oracle Database does the following:
- Closes any open cursors.
- Frees some nonreusable memory (for example, memory for collection and long VARCHAR2 variables)
- Returns the package instantiation to the pool of reusable instantiations kept for this package.
Essentially this means, that the package state exists only during the package call. Not for the whole session.
So far I never had the need to use this pragma. But I can imagine some very very special situations, where this might become interesting.
7. You can compile a package even while another session is running it
In general this is not possible. Assuming a package is currently running. Or to say it in technical terms: We have an active session (Session A) executing a packaged procedure.
A second session (Session B) trying to do an “ALTER COMPILE PACKAGE (BODY)” would wait until session A finishes and will then afterwards try to compile the package. Upon success the first session A then will get a “package state has been discarded” error message as soon as it tries to run the same package once again. The second next try to run the package would succeed and will use the new package version. At that time the package state was discarded from the session and the new instantiation can be loaded.
This is all documented and well known behaviour.
We face three potential issues with this
- Session B needs to wait
- Session A might get an error
- Session B might wait so long that the developer decides to kill the client (closing SQL developer) thereby making everything 10 times worse, because the database compile call still is valid on the database session level – blocking all following attempts to run or compile the package.
EBR for the rescue!
Using Edition Based Redefinition (EBR) we can circumvent those issues.
Both sessions just need to use different editions. EBR allows us to store and run different code versions of the same plsql based object in the same database.
preparation
First create a package with a long running procedure. My example uses a procedure that runs for exactly 1 minute.
create or replace package myPck is
procedure runMinute;
end myPck;
/
create or replace package body myPck is
procedure runMinute is
begin
sys.dbms_lock.sleep(60);
end runMinute;
end myPck;
/
Setup an edition DEV$ALPHA that is a child of the default edition (ORA$BASE).
create edition DEV$ALPHA;
You need an edition enabled schema to do this.
This is simple to do, but to explain EBR in more detail is beyond the scope of this blog post.
Example scenario
Lets run a few commands in two different sessions.
Session A resembles a USER/TESTER who currently executes the packaged function.
Session B resembles a DEVELOPER who wants to deploy a new version of the package.
Session A does this
set time on
alter session set edition=ORA$BASE;
execute myPck.runMinute;
Session B was started already and after the execute in Session A, run the following script in Session B.
alter session set edition=DEV$ALPHA;
— add a new procedure to the package
create or replace editionable package myPck …
/
create or replace editionable package body myPck …
/
— run the new procedure
exec myPck.run5secs;
Result is Session B finishes way before Session A does complete its 1 minute run.
See screenshot
q.e.d.
6. call a (pipelined) table function without the TABLE operator
It works only from 12.2 onwards. It is more of a SQL feature than a plsql one.
This will make a table function look indistinguishable from a parametrized view.
Example: split_string
First lets create a simple little table function. This one here just converts a delimited list into rows.
create or replace function split_string
(p_str IN VARCHAR2
,p_delimiter IN VARCHAR2 default ','
) RETURN sys.odcivarchar2list PIPELINED
IS
/** Function to split strings based upon delimiter
*
* @author Sven Weller
*
* @param p_str input string
* @param p_delimiter delimiter string, default =, Delimiter should only be 1 char.
* @return list of strings
*
*/
v_entry varchar2(4000);
v_remaining_str varchar2(4000);
BEGIN
-- input string needs to hold something to be able to split
if p_str is not null then
<<steps>>
for i in 1..regexp_count(p_str,'\'||p_delimiter)+1 loop
-- search + split
v_entry := rtrim(regexp_substr(p_str,'[^\'||p_delimiter||']*('||p_delimiter||'|$)',1,i),p_delimiter);
pipe row(v_entry);
end loop steps;
else raise no_data_found;
end if;
END split_string;
/
function created.
in 11g we call the function like this:
select * from TABLE(split_string('A:BB::CCC',':'));
in 12.2 we can now call it like that:
select * from split_string('A:BB::CCC',':');
As you can see the TABLE row source operator is gone. And it still works! The results of both statements are identical.
Want to test it? I made an example on livesql.com.
At the moment this is an undocumented 12.2 feature. So don’t use it for production code (yet). I quite like it. Less code is better! It might become some de-facto standard (similar to connect by level) and eventually will make it into the documentation.
5. dot notation for parameters
We can refer to parameters using the name of the module that declared them. This is useful when we need to distinguish a parameter from a column name.
example
create or replace function myFancyFunc (dummy in varchar2) return number
is
ret number := 0;
begin
begin
select 1 into ret
from dual
where dummy = myFancyFunc.dummy
and rownum = 1;
exception
when no_data_found then null;
end;
return ret;
end myFancyFunc;
/
Function MYFANCYFUNC compiled
select myFancyFunc('X') from dual;
1
select myFancyFunc('Y') from dual;
0
The function simply compares the value in the dummy column of the dual table to the value we input. If instead we would just compare dummy=dummy then we would get always 1 as a result. No matter what the input is. Even if we add an alias to the table and prefix the column with an alias, the non aliased “dummy” will still be interpreted as a column.
This behaviour is documented: Oracle Doc 12.1 – plsql name resolution
If a SQL statement references a name that belongs to both a column
and either a local variable or formal parameter,
then the column name takes precedence.
Interestingly we can also use labels on block level for specifying variables that are defined in this block.
set serveroutput on
<<main>>
declare
dummy varchar2(10) := 'Y';
begin
<<block1>>
declare
dummy varchar2(10) := 'X';
begin
<<block2>>
declare
dummy varchar2(10) := 'A';
begin
select dummy
into dummy
from dual
where dummy = block1.dummy;
dbms_output.put_line('MainBlock:'||main.dummy);
dbms_output.put_line('Block1:'||block1.dummy);
dbms_output.put_line('Block2:'||block2.dummy);
end block2;
end block1;
end main;
/
PL/SQL procedure successfully completed.
MainBlock:Y
Block1:X
Block2:X
Without dot notation the innermost variable (block2) is used – as we can see in the INTO part. And we can reference a different variable with the same name from a “higher” declaration by using the dot notation.
4. variable names can be emojis
example
set serveroutput on
declare
"💩"exception;
pragma exception_init("💩",-20001);
"⌚" timestamp := systimestamp;
"🕑"interval day to second;
"🎲"number;
"💤"number := 2;
begin
"🎲":= round(dbms_random.value(1,6));
for "🔜"in 1.."🎲"loop
dbms_lock.sleep("💤");
end loop;
"🕑":= systimestamp - "⌚" ;
dbms_output.put_line('Slept for '|| "🕑");
exception
when "💩"then
dbms_output.put_line('Sorry something bad happend!');
raise "💩";
end;
/
PL/SQL procedure successfully completed.
Slept for +00 00:00:08.049000
The source code looks a little bit different in sql developer. But trust me. I simply copy&pasted it from there to here.
To make this work you need to use a font that supports emoijs/symbols, I used font “Segoe UI Symbol”. It is supposed to look better on windows 10[3].
If you are a hard core emoji lover then I suggest to have a look at emojicode.org
It is a emoji based programming language. Which did not make it into the esoteric programming languages list (yet). Ook? Ook!
3. variables can be made mandatory (NOT NULL)
Check out the NOT NULL keyword during the variable declaration.
declare
v_index number not null := 0;
begin
v_index := 1;
v_index := null;
end;
/
Error report –
ORA-06550: line 5, column 14: PLS-00382: expression is of wrong type
ORA-06550: line 5, column 3: PL/SQL: Statement ignored
The error message is a bit vague about what happened, but it is very exact where it happened (line 5, column 14). And what do we see there? A NULL expression.
The expression is of wrong type, because we added a NOT NULL constraint to the number type that was used. For more complex cases we can create our own sub types and use them. But if we just want to make sure that we do not need to consider null cases during further variable calls, then this is a possible way.
Link to plsql documentation
Currently there are no such other constraints that we can use. I could imagine with the potential arrival of SQL assertions, this might become a hot topic in plsql too.
2. you can “hack” dbms_output
Warning! This is dangerous. It might break some (poorly written) code that resides in the same schema. Do it at your own risk! It is also hilariously funny to do on april fools day to your fellow coworkers. I mean they shouldn’t use dbms_output anyway. That will teach them!
I start the example by showing the behaviour first. Then the code to produce this result.
behaviour
create or replace procedure doSomething is
v_dummy dual.dummy%type;
begin
select dummy into v_dummy from dual where 1=2;
exception
when others then
dbms_output.put_line(sqlerrm);
end doSomething;
/
Now we run the module a couple of times and want to see the output. We should expect a NO_DATA_FOUND error message.
set serveroutput on
execute doSomething;
execute doSomething;
execute doSomething;
execute doSomething;
execute doSomething;
Surprisingly instead of the error message we get something like this.
PL/SQL procedure successfully completed.
Wrong usage of DBMS_OUTPUT detected.
PL/SQL procedure successfully completed.
Make Databases Great Again!
PL/SQL procedure successfully completed.
ORA-01403: no data found
PL/SQL procedure successfully completed.
Make Databases Great Again!
PL/SQL procedure successfully completed.
So tell me what you want, what you really, really want
Omg! What is going on here?
Well here is the catch. We can “overload” dbms_output in our own schema. Then the local package is called and not the original package from sys.
source code
create or replace package dbms_output
as
procedure enable(BUFFER_SIZE number default null);
procedure put_line(A in varchar2);
procedure GET_LINE(LINE out VARCHAR2,STATUS out integer);
procedure GET_LINES(LINES out sys.dbms_output.CHARARR,NUMLINES in out NUMBER);
procedure GET_LINES(LINES out sys.DBMSOUTPUT_LINESARRAY,NUMLINES in out NUMBER);
end dbms_output ;
/
create or replace package body dbms_output
as
procedure enable(BUFFER_SIZE number default null) is
begin
sys.dbms_output.enable(BUFFER_SIZE);
end;
function getRandomQuote (A in varchar2) return varchar2
is
type quotes_t is table of varchar2(4000) index by binary_integer;
v_quotes quotes_t;
v_random binary_integer;
begin
v_quotes(1) := 'You are hacked by the Chinese';
v_quotes(2) := 'Wrong usage of DBMS_OUTPUT detected.';
v_quotes(3) := 'System failure. Get away from keyboard';
v_quotes(4) := 'Close all windows! NOW!';
v_quotes(5) := 'Make Databases Great Again!';
v_quotes(6) := A; -- sometimes return the correct text
v_quotes(7) := A; -- sometimes return the correct text
v_quotes(8) := 'So tell me what you want, what you really, really want';
v_quotes(9) := 'None but ourselves can free our minds.';
v_quotes(10) := 'Let there be light!';
v_random := round(dbms_random.value(1,v_quotes.last));
return v_quotes(v_random);
end getRandomQuote;
procedure put_line(A in varchar2) is
begin
sys.dbms_output.put_line(getRandomQuote(A));
end;
procedure GET_LINE(LINE out VARCHAR2,STATUS out integer)
is
begin
sys.dbms_output.GET_LINE(LINE,STATUS);
end;
procedure GET_LINES(LINES out sys.dbms_output.CHARARR,NUMLINES in out NUMBER)
is
begin
sys.dbms_output.GET_LINES(LINES,NUMLINES);
end;
procedure GET_LINES(LINES out sys.DBMSOUTPUT_LINESARRAY,NUMLINES in out NUMBER)
is
begin
sys.dbms_output.GET_LINES(LINES,NUMLINES);
end;
end dbms_output ;
/
How does it work?
Because how sql name resolution kicks in, the DBMS_OUTPUT package in our schema is used and not the public synonym for the DBMS_OUTPUT package from the sys schema.
The get_line functions then pushes the changed text to the normal buffer mechanism.
How can we avoid it?
Best is not to use DBMS_OUTPUT in real production code. It is a nice quick debugging tool. But not more than that.
Also if you prefix dbms_output always with the SYS schema, then it will call the original logic.
1. when others does not catch all exceptions
example
set serveroutput on
declare
e_cancelled exception;
pragma exception_init(e_cancelled, -1013);
begin
begin
raise e_cancelled;
exception
when others then
dbms_output.put_line('EXCEPTION OTHERS');
end;
end;
/
ORA-01013: user requested cancel of current operation
ORA-06512: at line 6
We still see an exception, but not the dbms buffer output!
This needs some explanation.
There is a very limited set of exceptions that will not be captured by the WHEN OTHERS handler. We need to look closely and understand the exception itself to comprehend why this is a good thing.
Here the ORA-01013 is the “user requested cancel of current operation” exception. Essentially it means somebody pressed “CTRL+C” while running the code. In almost all environments this means: Stop doing whatever you do immediately! Or in more technical terms: It is an interrupt to the os process running your command. Same as executing “kill -2” (kill -SIGINT) in a nix environment (the-3-most-important-kill-signals-on-the-linux-unix-command-line). Even if the process is allowed to ignore the command, it shouldn’t do so by default.
ORA-01013 can sometimes also be the result of a timeout. Where the client is waiting for a response and after some time sends this as a timeout signal to the database session.
We are allowed to capture this exception and write a special handler for it.
set serveroutput on
declare
e_cancelled exception;
pragma exception_init(e_cancelled, -1013);
begin
begin
raise e_cancelled;
exception
when others then
dbms_output.put_line('EXCEPTION OTHERS');
end;
exception
when e_cancelled then
dbms_output.put_line('OPERATION CANCELED');
END;
/
PL/SQL procedure successfully completed.
OPERATION CANCELED
Nothing to worry about. Just nice to know.
Please note: This example will behave differently in older outdated db versions. I think it was introduced as a fix for bug#12838063 in 11.2.0.4.
Other exceptions that are not handled include “ORA-03113: end-of-file on communication channel”.
But not “ORA-06508: PL/SQL: could not find program unit being called”. This was supposed to go through “when others” but testing on 12.2.0.1 revealed it is captured.
svenweller 