| From: | Haritabh Gupta <haritabh1992(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Subject: | Re: proposal: schema variables |
| Date: | 2026-03-04 10:02:11 |
| Message-ID: | 177261853144.1094601.11795093672679754617.pgcf@coridan.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shveta malik | 2026-03-04 10:24:35 | Re: [PATCH] Support automatic sequence replication |
| Previous Message | Nitin Motiani | 2026-03-04 09:57:14 | Re: Adding pg_dump flag for parallel export to pipes |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Andrei Lepikhov | 2026-02-27 15:35:31 | Re: unstable query plan on pg 16,17,18 |