Cursors let you look at query results one row at a time. This helps when you want to handle data step-by-step instead of all at once.
Cursor declaration and usage in PostgreSQL
Start learning this pattern below
Jump into concepts and practice - no test required
DECLARE cursor_name CURSOR FOR select_statement;
OPEN cursor_name;
FETCH cursor_name INTO target_variable;
CLOSE cursor_name;You declare a cursor with a name and a SELECT query.
Use OPEN to start the cursor, FETCH to get rows one by one, and CLOSE when done.
emp_cursor to select employee IDs and names.DECLARE emp_cursor CURSOR FOR SELECT id, name FROM employees;
emp_id and emp_name.OPEN emp_cursor;
FETCH emp_cursor INTO emp_id, emp_name;CLOSE emp_cursor;
This anonymous code block declares a cursor to select employee IDs and names ordered by ID. It opens the cursor, fetches each row one by one, prints the employee details, and closes the cursor.
DO $$ DECLARE emp_cursor CURSOR FOR SELECT id, name FROM employees ORDER BY id; emp_id INT; emp_name TEXT; BEGIN OPEN emp_cursor; LOOP FETCH emp_cursor INTO emp_id, emp_name; EXIT WHEN NOT FOUND; RAISE NOTICE 'Employee ID: %, Name: %', emp_id, emp_name; END LOOP; CLOSE emp_cursor; END $$;
Cursors are useful for row-by-row processing but can be slower than set-based queries.
Always close cursors to free resources.
Use EXIT WHEN NOT FOUND; to stop fetching when no more rows are available.
Cursors let you handle query results one row at a time.
Declare, open, fetch rows, and close the cursor in that order.
Use cursors when you need step-by-step control over data processing.
Practice
Solution
Step 1: Understand what a cursor does
A cursor allows you to handle query results row by row instead of all at once.Step 2: Compare options with cursor purpose
Only To process query results one row at a time describes this behavior; others describe unrelated tasks.Final Answer:
To process query results one row at a time -> Option BQuick Check:
Cursor purpose = process rows one by one [OK]
- Confusing cursors with table creation
- Thinking cursors speed up inserts
- Assuming cursors automate backups
cur_emp for selecting all rows from employees table?Solution
Step 1: Recall cursor declaration syntax
In PostgreSQL, cursors are declared with DECLARE cursor_name CURSOR FOR query.Step 2: Match syntax with options
DECLARE cur_emp CURSOR FOR SELECT * FROM employees; matches this exactly; others use incorrect keywords or order.Final Answer:
DECLARE cur_emp CURSOR FOR SELECT * FROM employees; -> Option CQuick Check:
DECLARE + CURSOR + FOR + query = correct syntax [OK]
- Using OPEN instead of DECLARE for declaration
- Confusing FETCH with DECLARE
- Using CREATE CURSOR which is invalid syntax
DECLARE cur_emp CURSOR FOR SELECT id FROM employees ORDER BY id LIMIT 3; OPEN cur_emp; FETCH NEXT FROM cur_emp; FETCH NEXT FROM cur_emp;
Solution
Step 1: Understand cursor declaration and fetch
The cursor selects 3 employee ids ordered ascending. FETCH NEXT retrieves one row each time.Step 2: Analyze fetch calls
Two FETCH NEXT calls return the first two rows from the cursor result.Final Answer:
First two employee ids in ascending order -> Option AQuick Check:
Two FETCH NEXT = two rows fetched [OK]
- Assuming FETCH returns all rows at once
- Thinking missing CLOSE causes syntax error
- Believing cursor must be closed before fetching
DECLARE cur_dept CURSOR FOR SELECT name FROM departments; FETCH NEXT FROM cur_dept; OPEN cur_dept; CLOSE cur_dept;
Solution
Step 1: Check the order of cursor operations
Cursors must be declared, then opened, then fetched, then closed.Step 2: Identify incorrect sequence
Here, FETCH is called before OPEN, which is invalid.Final Answer:
Cursor is fetched before it is opened -> Option DQuick Check:
OPEN must precede FETCH [OK]
- Fetching before opening cursor
- Closing cursor before opening
- Misordering declaration and fetch
orders table one by one using a cursor in a PL/pgSQL function. Which sequence of statements correctly implements this?Solution
Step 1: Understand correct cursor usage in PL/pgSQL
Declare cursor, open it, then loop fetching rows until no more rows, then close cursor.Step 2: Analyze each option
DECLARE cur_orders CURSOR FOR SELECT * FROM orders; OPEN cur_orders; LOOP FETCH cur_orders INTO rec; EXIT WHEN NOT FOUND; -- process rec END LOOP; CLOSE cur_orders; follows correct order and uses LOOP with EXIT WHEN NOT FOUND to process all rows. Others have wrong order or invalid FETCH ALL.Final Answer:
DECLARE cur_orders CURSOR FOR SELECT * FROM orders; OPEN cur_orders; LOOP FETCH cur_orders INTO rec; EXIT WHEN NOT FOUND; -- process rec END LOOP; CLOSE cur_orders; -> Option AQuick Check:
Declare, Open, Loop Fetch, Close = correct pattern [OK]
- Opening cursor before declaring
- Fetching before opening
- Using FETCH ALL which is invalid for cursors
