SPI_EXEC..._EXTENDED(3)

💖 SPI_EXECUTE_PLAN_EXTENDED 💖

okay bestie, gather round, because we're about to talk about SPI_execute_plan_extended from the PostgreSQL 18.6 docs, and honestly? it's giving ✨main character energy✨ for anyone writing C extensions. 🦋

---

✨ NAME ✨

SPI_execute_plan_extended — execute a statement prepared by SPI_prepare 💅

---

✨ SYNOPSIS ✨

int SPI_execute_plan_extended(SPIPlanPtr plan,
                              const SPIExecuteOptions * options)

---

✨ DESCRIPTION ✨

so SPI_execute_plan_extended runs a statement that was prepared by SPI_prepare or one of its siblings. 🌸

It's basically SPI_execute_plan's cooler twin — same energy, but the info about the parameter values you're passing to the query gets presented differently, and you also get extra execution-controlling options to play with. 🎀

Your query parameter values are represented by a ParamListInfo struct, which is lowkey so convenient when you've already got values chillin' in that exact format. And dynamic parameter sets? Also a thing! Via hook functions specified in ParamListInfo. 🪄

AND, the best part, ngl: instead of always accumulating the result tuples into a SPI_tuptable structure, you can hand tuples off to a caller-supplied DestReceiver object as the executor generates them. This is iconic for queries that might generate a LOT of tuples, because the data gets processed on-the-fly instead of being accumulated in memory. 🧠💖

---

✨ ARGUMENTS ✨

• SPIPlanPtr plan — the prepared statement (returned by SPI_prepare) 🫶
• const SPIExecuteOptions * options — struct containing optional arguments

⚠️ okay important one bestie: callers should always zero out the entire options struct, then fill whichever fields they want to set. This ensures forward compatibility of your code, since any fields added to the struct in future will be defined to behave backwards-compatibly if they are zero. no cap. 💀

The currently available options fields are:

• ParamListInfo params — data structure containing query parameter types and values; NULL if none
• bool read_only — true for read-only execution
• bool allow_nonatomic — true allows non-atomic execution of CALL and DO statements (but this field is ignored unless the SPI_OPT_NONATOMIC flag was passed to SPI_connect_ext) 🚨
• bool must_return_tuples — if true, raise error if the query is not of a kind that returns tuples (this does not forbid the case where it happens to return zero tuples)
• uint64 tcount — maximum number of rows to return, or 0 for no limit
• DestReceiver * dest — DestReceiver object that will receive any tuples emitted by the query; if NULL, result tuples are accumulated into a SPI_tuptable structure, as in SPI_execute_plan
• ResourceOwner owner — The resource owner that will hold a reference count on the plan while it is executed. If NULL, CurrentResourceOwner is used. Ignored for non-saved plans, as SPI does not acquire reference counts on those.

---

✨ RETURN VALUE ✨

The return value is the same as for SPI_execute_plan. simple as that. 😌

When options->dest is NULL, SPI_processed and SPI_tuptable are set as in SPI_execute_plan. 🌷

When options->dest is not NULL, SPI_processed is set to zero and SPI_tuptable is set to NULL. So if a tuple count is required, the caller's DestReceiver object must calculate it. 👑 (not me making you do your own math tho 😭)

---

and that's the whole page, bestie!! 💜 this was PostgreSQL 18.6 documentation, dated 2026, and you absolutely ate that read. go forth and prepare those statements. slay. 💅✨🎀