Horton

Re: proposal: schema variables

Haritabh Gupta <haritabh1992@gmail.com>

View thread View on postgr.es
From: Haritabh Gupta <haritabh1992@gmail.com>
To: pgsql-hackers@lists.postgresql.org
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Date: 2026-03-04T10:02:11Z
Lists: pgsql-hackers, pgsql-performance 
Hi,

While reviewing I came across this behaviour and wanted to
check whether it's intended:

    CREATE TEMP VARIABLE y AS int;
    LET y = 42;

    BEGIN;
    SAVEPOINT s1;
    LET y = generate_series(1,2);  -- ERROR: too many rows
    ROLLBACK TO s1;
    SELECT VARIABLE(y);            -- returns 1, not 42

It looks like svariableReceiveSlot writes the first row to the
variable (pfree'ing the old datum) before the second row triggers the
error, so the old value is lost even though LET failed.

I understand variable values are intentionally non-transactional, but
is it expected that a failed LET has this side effect? 

---
Haritabh Gupta
Supabase

Commits

  1. Reduce LEFT JOIN to ANTI JOIN using NOT NULL constraints

  2. Move WAL sequence code into its own file

  3. Add ExplainState argument to pg_plan_query() and planner().

  4. Don't include access/htup_details.h in executor/tuptable.h

  5. Refactor to avoid code duplication in transformPLAssignStmt.

  6. Avoid including commands/dbcommands.h in so many places

  7. Restrict psql meta-commands in plain-text dumps.

  8. Split func.sgml into more manageable pieces

  9. Fix squashing algorithm for query texts

  10. EXPLAIN: Always use two fractional digits for row counts.

  11. Preliminary refactoring of plpgsql expression construction.

  12. plpgsql: pure parser and reentrant scanner

  13. Add some sanity checks in executor for query ID reporting

  14. Fix misleading error message context

  15. Add macros for looping through a List without a ListCell.