Performing operations on cursors in PostgreSQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

Output of FETCH with SCROLL cursor

Consider the following PostgreSQL commands executed in order:

BEGIN;
DECLARE mycursor SCROLL CURSOR FOR SELECT generate_series(1,5);
FETCH ABSOLUTE 3 FROM mycursor;

What is the output of the FETCH command?

PostgreSQL

BEGIN;
DECLARE mycursor SCROLL CURSOR FOR SELECT generate_series(1,5);
FETCH ABSOLUTE 3 FROM mycursor;

A 3

B 1

C 5

D NULL

💡 Hint

The ABSOLUTE option fetches the row at the exact position in the result set.

The cursor selects numbers 1 to 5. FETCH ABSOLUTE 3 returns the third row, which is 3.

📝 Syntax

intermediate

Identify the syntax error in cursor declaration

Which of the following cursor declarations is syntactically correct in PostgreSQL?

A DECLARE cur1 CURSOR IN SELECT * FROM users;

B DECLARE cur1 CURSOR SELECT * FROM users;

C DECLARE cur1 CURSOR FOR (SELECT * FROM users);

D DECLARE cur1 CURSOR FOR SELECT * FROM users;

💡 Hint

Cursor declaration requires the keyword FOR before the query.

Option D correctly uses DECLARE cur1 CURSOR FOR followed by the SELECT statement. Other options miss FOR or use invalid syntax.

❓ optimization

advanced

Optimizing cursor usage for large datasets

You need to process a large table row by row using a cursor in PostgreSQL. Which option optimizes memory usage and avoids locking the entire table during processing?

A DECLARE cur NO SCROLL CURSOR WITH HOLD FOR SELECT * FROM large_table;

B DECLARE cur NO SCROLL CURSOR FOR SELECT * FROM large_table;

C DECLARE cur CURSOR FOR SELECT * FROM large_table;

D DECLARE cur SCROLL CURSOR WITH HOLD FOR SELECT * FROM large_table;

💡 Hint

WITH HOLD allows cursor to remain open after commit, NO SCROLL reduces overhead.

Option B uses NO SCROLL to reduce overhead and avoids locking by not using WITH HOLD, which keeps the cursor tied to the transaction. WITH HOLD cursors remain open after commit but can hold locks longer.

🔧 Debug

advanced

Debugging cursor fetch error

Given the following commands:

BEGIN;
DECLARE mycur CURSOR FOR SELECT id FROM products WHERE price > 100;
FETCH NEXT FROM mycur;
FETCH PRIOR FROM mycur;

What error will the last FETCH cause?

A ERROR: cursor is not scrollable

B ERROR: no prior row found

C ERROR: cursor does not exist

D No error, returns previous row

💡 Hint

By default, cursors are not scrollable unless declared SCROLL.

The cursor was declared without SCROLL, so FETCH PRIOR causes an error because the cursor cannot move backward.

🧠 Conceptual

expert

Understanding cursor behavior with transaction commits

In PostgreSQL, what happens to a cursor declared WITHOUT the WITH HOLD option when the transaction that declared it commits?

A The cursor resets to the first row but remains open

B The cursor remains open and usable in subsequent transactions

C The cursor is automatically closed and cannot be used further

D The cursor switches to read-only mode

💡 Hint

WITH HOLD controls cursor persistence after commit.

Cursors declared without WITH HOLD close automatically at transaction commit and cannot be used afterward.

Practice

1. What is the primary purpose of using a cursor in PostgreSQL?

easy

A. To process query results one row at a time

B. To speed up query execution by parallel processing

C. To permanently store query results in a table

D. To automatically optimize query plans

Solution

1. Step 1: Understand what a cursor does

   A cursor allows you to handle query results row by row instead of all at once.

2. Step 2: Compare options

   Only To process query results one row at a time correctly describes this row-wise processing purpose.

3. Final Answer:

   To process query results one row at a time -> Option A

4. Quick Check:

   Cursor = row-by-row processing [OK]

Hint: Cursors process rows one by one, not all at once [OK]

Common Mistakes:

• Thinking cursors speed up queries automatically
• Confusing cursors with temporary tables
• Assuming cursors optimize query plans

2. Which of the following is the correct syntax to declare a cursor named cur1 for a SELECT query in PostgreSQL?

easy

A. OPEN cur1 CURSOR FOR SELECT * FROM employees;

B. DECLARE cur1 CURSOR FOR SELECT * FROM employees;

C. FETCH cur1 CURSOR FOR SELECT * FROM employees;

D. CREATE CURSOR cur1 FOR SELECT * FROM employees;

Solution

1. Step 1: Recall cursor declaration syntax

   In PostgreSQL, cursors are declared using DECLARE cursor_name CURSOR FOR query.

2. Step 2: Match syntax with options

   DECLARE cur1 CURSOR FOR SELECT * FROM employees; matches the correct DECLARE syntax; others misuse OPEN, FETCH, or CREATE.

3. Final Answer:

   DECLARE cur1 CURSOR FOR SELECT * FROM employees; -> Option B

4. Quick Check:

   DECLARE cursor FOR query [OK]

Hint: Use DECLARE to define cursor before OPEN or FETCH [OK]

Common Mistakes:

• Using OPEN instead of DECLARE to define cursor
• Trying to FETCH during declaration
• Using CREATE CURSOR which is invalid

3. Consider this PostgreSQL code snippet:

DECLARE cur CURSOR FOR SELECT id FROM users ORDER BY id;
OPEN cur;
FETCH NEXT FROM cur;
FETCH NEXT FROM cur;
CLOSE cur;

What will be the output of the two FETCH commands if the users table has ids 10, 20, 30 in ascending order?

medium

A. First FETCH returns 10, second FETCH returns 20

B. First FETCH returns 20, second FETCH returns 30

C. Both FETCH commands return 10

D. First FETCH returns 30, second FETCH returns NULL

Solution

1. Step 1: Understand cursor order and FETCH

   The cursor selects ids ordered by id: 10, 20, 30. FETCH NEXT returns rows sequentially.

2. Step 2: Trace FETCH commands

   First FETCH returns the first row: 10. Second FETCH returns the next row: 20.

3. Final Answer:

   First FETCH returns 10, second FETCH returns 20 -> Option A

4. Quick Check:

   FETCH NEXT returns rows in order [OK]

Hint: FETCH NEXT returns rows in declared order one by one [OK]

Common Mistakes:

• Assuming FETCH skips rows
• Confusing FETCH NEXT with FETCH ALL
• Expecting FETCH to return NULL before end

4. Given this code snippet:

DECLARE cur CURSOR FOR SELECT name FROM products;
OPEN cur;
FETCH cur;
CLOSE cur;
FETCH cur;

What error will occur when running this code?

medium

A. ERROR: cursor "cur" does not exist

B. No error, FETCH returns next row

C. ERROR: syntax error near FETCH

D. ERROR: cursor "cur" is not open

Solution

1. Step 1: Analyze cursor lifecycle

   Cursor is declared and opened, then FETCH is called once, then cursor is closed.

2. Step 2: Identify error on second FETCH

   After CLOSE, cursor is not open, so FETCH causes "cursor is not open" error.

3. Final Answer:

   ERROR: cursor "cur" is not open -> Option D

4. Quick Check:

   FETCH after CLOSE causes 'not open' error [OK]

Hint: Cannot FETCH after CLOSE; cursor must be open [OK]

Common Mistakes:

• Trying to FETCH after cursor is closed
• Expecting FETCH to reopen cursor automatically
• Confusing 'not open' with 'does not exist' error

5. You want to process a large table orders row by row using a cursor in a PL/pgSQL function. Which sequence of commands correctly opens the cursor, fetches all rows one by one, and closes it after processing?

hard

A. DECLARE cur CURSOR FOR SELECT * FROM orders; OPEN cur; FETCH ALL FROM cur; CLOSE cur;

B. OPEN cur; DECLARE cur CURSOR FOR SELECT * FROM orders; FETCH cur INTO rec; CLOSE cur;

C. DECLARE cur CURSOR FOR SELECT * FROM orders; OPEN cur; LOOP FETCH cur INTO rec; EXIT WHEN NOT FOUND; -- process rec END LOOP; CLOSE cur;

D. DECLARE cur CURSOR FOR SELECT * FROM orders; FETCH cur INTO rec; OPEN cur; CLOSE cur;

Solution

1. Step 1: Understand correct cursor usage in PL/pgSQL

   Declare cursor, open it, then loop fetching rows until no more rows (EXIT WHEN NOT FOUND), then close cursor.

2. Step 2: Evaluate options

   DECLARE cur CURSOR FOR SELECT * FROM orders; OPEN cur; LOOP FETCH cur INTO rec; EXIT WHEN NOT FOUND; -- process rec END LOOP; CLOSE cur; correctly shows DECLARE, OPEN, LOOP with FETCH and EXIT, then CLOSE. Others misuse order or FETCH ALL which fetches all rows at once.

3. Final Answer:

   DECLARE cur CURSOR FOR SELECT * FROM orders; OPEN cur; LOOP FETCH cur INTO rec; EXIT WHEN NOT FOUND; -- process rec END LOOP; CLOSE cur; -> Option C

4. Quick Check:

   Cursor loop with FETCH and EXIT WHEN NOT FOUND [OK]

Hint: Use LOOP with FETCH and EXIT WHEN NOT FOUND to process cursor rows [OK]

Common Mistakes:

• Opening cursor after FETCH
• Using FETCH ALL instead of looping FETCH
• Closing cursor before processing all rows