SPI_IS_CURSOR_PLAN(3)

🦋 SPI_IS_CURSOR_PLAN(3) — can this plan open a cursor, bestie? 🦋

okay so this is straight from the PostgreSQL 13.23 documentation, and we're doing a vibe check on SPI_is_cursor_plan 💅

---

✨ NAME ✨

SPI_is_cursor_plan — returns true if a statement prepared by SPI_prepare can be used with SPI_cursor_open 🫶

---

🌸 SYNOPSIS 🌸

bool SPI_is_cursor_plan(SPIPlanPtr plan)

---

💖 DESCRIPTION 💖

SPI_is_cursor_plan returns true if a statement prepared by SPI_prepare can be passed as an argument to SPI_cursor_open, or false if that is not the case. no cap, that's the whole function's main-character job ✨

The criteria are literally that the plan represents one single command and that this command returns tuples to the caller 😌 for example, SELECT is allowed unless it contains an INTO clause, and UPDATE is allowed only if it contains a RETURNING clause. periodt.

---

🎀 ARGUMENTS 🎀

• SPIPlanPtr plan — the prepared statement, aka the thing returned by SPI_prepare 🍓

---

🔥 RETURN VALUE 🔥

true or false to indicate if the plan can produce a cursor or not, with SPI_result set to zero 👑

If it is not possible to determine the answer — for example, if the plan is NULL or invalid, or if called when not connected to SPI — then SPI_result is set to a suitable error code and false is returned. so yeah, sometimes the answer is just "bestie, I literally can't even" 😭

tiny but important: false can mean either "nope, no cursor from this plan" or "couldn't figure it out", and SPI_result is where the extra tea lives ☕

---

okay that's the whole page, mwah 💋 it's from PostgreSQL 13.23 documentation, dated 2025, and it's the SPI_IS_CURSOR_PLAN(3) manual page — slay 🦋💖