Last week, I posted this on Twitter:
What code can be removed w/o changing text shown after execution?
![]()
Who Said What?
evrocs_nl putting data in collection before the select, because the bulk collect will clear the collection first (unless really old oracle)
Yes! A BULK COLLECT always empties the target collection. If the query returns no data, the collection remains empty. Otherwise its contents are replaced by the result set of the query.
MDWidlake All of it as you forgot to turn serveroutput on anyway. Where do I collect my Kewpie doll?
Oh, Martin, you clever fellow. There's always one in a crowd. But sort of good point. This exercise was taken from the PL/SQL Challenge, whose PL/SQL quiz assumptions include that SERVEROUTPUT is always on.
ddfdba indx pls_integer:=100; l_empty objects_t; := l_empty
Yes! There is no need to declare a variable for the iterator used in a FOR loop; it is declared implicitly by PL/SQL. There is, furthermore, need to assign an "empty" collection to l_objects to initialize it. A BULK COLLECT automatically initializes a nested table, if it has not already been initialized.
gurcan_orhanwhere's the exception (when others then null;)
Well, Gurcan, your text was not relevant to the exercise at hand, but it is always an important question to ask a programmer about their subprogram:
"Where's the exception section?"
The answer might well be "We handle exceptions in an outer block." and that could be a fine answer, but it never hurts to check.
patch72both declarations of indx. l_empty variable. Assignment with l_empty. l_object(100) := 'BLIP'; l_objects.delete.
Yes! Some of this was already addressed, but Patrick points out that there is no need to delete all the elements from the collection. Why not? Because PL/SQL is such a fantastic, hard-working programming language. The l_objects collection is declared within the nested subprogram. Consequently, the PL/SQL runtime engine automatically releases the memory for l_objects when the execute of get_objects terminates. Nice work, PL/SQL!
yalimgerger, chetanr009, I_am_mvrolijk offered several of the same observations as those above. Thanks for taking the time to tweet!
rtripathi6 suggested removing "The FOR indx IN 1 .. l_objects.COUNT loop." But I do not see how the subprogram will compile without it. Perhaps you can clarify with a comment?
Here's a pretty picture driving home all the code that could be removed from this block:
![]()
Lessons Learned
PL/SQL is a purpose-built language for writing high performance, easy to maintain and very secure applications on top of Oracle SQL and the Oracle Database.
Because of its tight focus, the PL/SQL development team has been able to optimize syntax, garbage cleanup, and more.
The more you understand what PL/SQL does for you, the more easily you will be able to leverage PL/SQL to deliver applications on-time and on-budget.
What code can be removed w/o changing text shown after execution?
Who Said What?
evrocs_nl putting data in collection before the select, because the bulk collect will clear the collection first (unless really old oracle)
Yes! A BULK COLLECT always empties the target collection. If the query returns no data, the collection remains empty. Otherwise its contents are replaced by the result set of the query.
MDWidlake All of it as you forgot to turn serveroutput on anyway. Where do I collect my Kewpie doll?
Oh, Martin, you clever fellow. There's always one in a crowd. But sort of good point. This exercise was taken from the PL/SQL Challenge, whose PL/SQL quiz assumptions include that SERVEROUTPUT is always on.
ddfdba indx pls_integer:=100; l_empty objects_t; := l_empty
Yes! There is no need to declare a variable for the iterator used in a FOR loop; it is declared implicitly by PL/SQL. There is, furthermore, need to assign an "empty" collection to l_objects to initialize it. A BULK COLLECT automatically initializes a nested table, if it has not already been initialized.
gurcan_orhanwhere's the exception (when others then null;)
Well, Gurcan, your text was not relevant to the exercise at hand, but it is always an important question to ask a programmer about their subprogram:
"Where's the exception section?"
The answer might well be "We handle exceptions in an outer block." and that could be a fine answer, but it never hurts to check.
patch72both declarations of indx. l_empty variable. Assignment with l_empty. l_object(100) := 'BLIP'; l_objects.delete.
Yes! Some of this was already addressed, but Patrick points out that there is no need to delete all the elements from the collection. Why not? Because PL/SQL is such a fantastic, hard-working programming language. The l_objects collection is declared within the nested subprogram. Consequently, the PL/SQL runtime engine automatically releases the memory for l_objects when the execute of get_objects terminates. Nice work, PL/SQL!
yalimgerger, chetanr009, I_am_mvrolijk offered several of the same observations as those above. Thanks for taking the time to tweet!
rtripathi6 suggested removing "The FOR indx IN 1 .. l_objects.COUNT loop." But I do not see how the subprogram will compile without it. Perhaps you can clarify with a comment?
Here's a pretty picture driving home all the code that could be removed from this block:
Lessons Learned
PL/SQL is a purpose-built language for writing high performance, easy to maintain and very secure applications on top of Oracle SQL and the Oracle Database.
Because of its tight focus, the PL/SQL development team has been able to optimize syntax, garbage cleanup, and more.
The more you understand what PL/SQL does for you, the more easily you will be able to leverage PL/SQL to deliver applications on-time and on-budget.