SPI_EXECUTE_EXTENDED(3)

💅 SPI_EXECUTE_EXTENDED(3) — the PostgreSQL 16.15 girlies' guide 💅

okay so bestie, welcome to the SPI_EXECUTE_EXTENDED page from the PostgreSQL 16.15 docs ✨ this is the one where you run a command that has lil out-of-line parameters, and honestly? it's giving main character energy 🎀

---

🌸 NAME 🌸

SPI_execute_extended — execute a command with out-of-line parameters 🦋

---

✨ SYNOPSIS ✨

int SPI_execute_extended(const char *command,
                         const SPIExecuteOptions * options)

---

💖 DESCRIPTION 💖

SPI_execute_extended executes a command that might include references to externally supplied parameters. fr fr, the command text refers to a parameter as $n, and the options->params object (if supplied) provides values and type information for each such symbol. Various execution options can be specified in the options struct, too — it's literally a whole vibe check in a struct 👑

The options->params object should normally mark each parameter with the PARAM_FLAG_CONST flag, since a one-shot plan is always used for the query. no cap, that's just how it goes 💅

If options->dest is not NULL, then result tuples are passed to that object as they are generated by the executor, instead of being accumulated in SPI_tuptable. Using a caller-supplied DestReceiver object is particularly helpful for queries that might generate many tuples, since the data can be processed on-the-fly instead of being accumulated in memory 🌈 like, streaming instead of hoarding? we love to see it 🫶

---

🎀 ARGUMENTS 🎀

• const char * command — command string 💬
• const SPIExecuteOptions * options — struct containing optional arguments 🧚

Callers should always zero out the entire options struct, then fill whichever fields they want to set. This ensures forward compatibility of code, since any fields that are added to the struct in future will be defined to behave backwards-compatibly if they are zero 🙈 that's the whole trick, bestie — zero it first, then decorate ✨

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) ⚠️ yeah, she's ignored unless you did the setup — read the fine print 💀
• 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) 🤔 so like. must be capable of returning tuples. zero is still valid, iconically 💅
• 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 📬
• ResourceOwner owner — This field is present for consistency with SPI_execute_plan_extended, but it is ignored, since the plan used by SPI_execute_extended is never saved 🙈 she's literally just there for the aesthetic, not doing anything 💀

---

⭐ RETURN VALUE ⭐

The return value is the same as for SPI_execute 👑

When options->dest is NULL, SPI_processed and SPI_tuptable are set as in SPI_execute. When options->dest is not NULL, SPI_processed is set to zero and SPI_tuptable is set to NULL. If a tuple count is required, the caller's DestReceiver object must calculate it 🧮 yes bestie, you have to count them yourself — nobody's gonna do it for you 🫶

---

🌟 reminder: zero the whole struct first, and don't forget PARAM_FLAG_CONST on your params. iykyk 💖

---

and that's the page!! 🎀 brought to you by PostgreSQL 16.15, dated 2026, with all the love in the world from the SPI_EXECUTE_EXTENDED(3) girlies 💜 mwah, go slay your queries ✨👑