SPI_SAVEPLAN(3)

💾 SPI_SAVEPLAN(3) — like, the save button for prepared statements ✨

okay bestie, so this is SPI_SAVEPLAN(3) from the PostgreSQL 14.24 docs, and honestly? it's a little memory-management baddie and i'm obsessed 🎀

---

✨ SYNOPSIS ✨

SPIPlanPtr SPI_saveplan(SPIPlanPtr plan)

---

💅 DESCRIPTION 💅

so here's the tea ☕ — SPI_saveplan copies a statement that got passed in (one that was prepared by SPI_prepare, iykyk) into memory that is not gonna get freed by SPI_finish, and not by the transaction manager either. then it hands you back a pointer to the copied statement. 🫶

the whole point? it's giving reuse. it gives you the ability to reuse prepared statements in the subsequent invocations of your C function in the current session. main character energy for your prepared statements, fr fr 👑

---

🌸 ARGUMENTS 🌸

• SPIPlanPtr plan — the prepared statement to be saved. that's it, that's the whole argument, she's lowkey simple 💖

---

⭐ RETURN VALUE ⭐

you get a pointer to the copied statement 💫 — or NULL if it didn't work out 😭. on error, SPI_result is set thus:

• SPI_ERROR_ARGUMENT — if plan is NULL or invalid 🙈
• SPI_ERROR_UNCONNECTED — if called from an unconnected C function 💀

---

🦋 NOTES 🦋

heads up: the originally passed-in statement is not freed, so you might wish to do SPI_freeplan on it to avoid leaking memory until SPI_finish. not me letting memory leak... don't do that bestie 🫶

also, in most cases, SPI_keepplan is preferred to this function, since it accomplishes largely the same result without needing to physically copy the prepared statement's data structures. so like... same vibe, less work? iconic, honestly 🌈

fr fr: if you don't need the physical copy, SPI_keepplan is the move 💅

---

🎀 and that's the page!! brought to you by PostgreSQL 14.24, dated 2026 — slay, stay hydrated, and don't leak your plans 💜✨