Re: proposal: schema variables

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Haritabh Gupta <haritabh1992@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2026-03-05T12:54:06Z
Lists: pgsql-hackers, pgsql-performance

Attachments

Hi

st 4. 3. 2026 v 11:03 odesílatel Haritabh Gupta <haritabh1992@gmail.com>
napsal:

> 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?
>

please, check attached patch

Regards

Pavel


>
> ---
> 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.