Is it possible to parse a cursor record into a function if so how?

Question

My question is basically as the title says. I would like to know if i can parse a cursor record through a function
for example
FOR r1 in c1
LOOP
calcuate(r1.mark1, r1.mark2,r1.mark3, r1.student)
END LOOP
where fucntion looks similar to
CREATE function calculate(mark1 NUMBER, mark2 NUMBER, mark3 NUMBER, student VARCHAR2(15))
RETURN NUMBER
IS
total NUMBER;
BEGIN
SELECT avg(all_marks) into total
from table
where mark1 = table.mark10 and
mark2 > 100 and
mark3 > 70;
return NVL(total,0);
end;
if this is not possible how else can i do the specific task, where a cursor record is used to do a similar query to what the function does.

Answer 1

> yes my system needs to be very efficient and with the least amount of code, besides this is for a
database programming assingment where pl/sql is the language we are meant to master thus pl/sql >
sql sad to say.
Sorry, I don't get it. You say that your system needs to be efficient and in the very same breath you say "Screw efficiency, I want to use PL/SQL and not SQL". That is a bs statement IMO.
There is a correct way. There is a wrong way. Choose one. It is not possible to do it correctly using the wrong principles, approach and code.
> can cursor fetch loop parse through a function or am i just dreaming for that shortcut??
What shortcut? A cursor is a SQL program. You are using PL/SQL to fetch from that cursor, iterating through it, does not change the fact that you are
a) dealing with a SQL program (aka cursor)
b) being serviced by the SQL engine
What shortcut do you imagine there is? Not dealing with the SQL engine at all? PL/SQL is two languages. It is PL, a Programming Language based on ADA. This is tightly integrated with the SQL language.
PL code is parsed and executed by the PL engine. SQL code is parsed and executed by the SQL engine. Each line of SQL code in PL/SQL, requires a context switch from the PL engine to the SQL engine in order for that SQL code to be executed. Each fetch from a cursor (via an explicit or implicit fetch), is a context switch to the SQL engine to execute that cursor in order to get the next set of (or single) rows.
The more context switches there are, the more overheads there are. Each context switch pulls and/or pushes data between the PL and SQL engines.
Okay, so now where is the "shortcut" - or more accurately called, correctly designing and coding PL/SQL?
This is achieved by not pulling data into the PL engine that you do not really need as your PL code only pushes that very same data back to the SQL engine.
This is achieved by reducing the number of context switches between the PL and SQL engines.
This is achieved by processing data sets and not rows, in the PL engine.
This is achieved by Maximizing SQL and minimizing PL/SQL.
Now if you do not like and want to play silly buggers with PL/SQL and Oracle, that's your decision. I'm sure some here will throw you a rope (by posting really smelly code) from the bottom of the Oracle scalability and performance hole and help you drag yourself into it.