SPI_SAVEPLAN(3)

✨ SPI_SAVEPLAN(3) ✨

okay so bestie, welcome to the SPI_SAVEPLAN(3) page — straight out of the PostgreSQL 16.15 documentation, section 3 if you're keeping track 💅. this one's about saving a prepared statement so it stays saved, and honestly? iconic behavior.

---

🎀 NAME 🎀

SPI_saveplan — save a prepared statement 🫶

---

🌸 SYNOPSIS 🌸

SPIPlanPtr SPI_saveplan(SPIPlanPtr plan)

---

🦋 DESCRIPTION 🦋

so what does it do? SPI_saveplan copies a statement you passed in (one that was prepared by SPI_prepare, obvs) into memory that will not be freed by SPI_finish and won't get freed by the transaction manager either 😤. then it hands you back a pointer to the copied statement.

and like… why do you care? bc this gives you the ability to reuse prepared statements in the subsequent invocations of your C function in the current session. that's the whole vibe. that's the point. ✨

---

💖 ARGUMENTS 💖

• SPIPlanPtr plan — the prepared statement to be saved, your main character of the moment 👑

---

🔥 RETURN VALUE 🔥

Pointer to the copied statement 🎉 — or NULL if unsuccessful 😭. on error, SPI_result gets set like this:

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

---

🌈 NOTES 🌈

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. like, memory leaks are not the aesthetic bestie, pls handle it 🫶

also, in most cases SPI_keepplan is preferred to this function — it accomplishes largely the same result without needing to physically copy the prepared statement's data structures. so maybe check that one out first? just saying 👀

---

and that's the whole page, no cap 💜 — this was SPI_SAVEPLAN(3) from the PostgreSQL 16.15 documentation, dated 2026. go forth and save those plans, queen 🧚‍♀️✨🎀