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?
Yes, it does like you describe it. It is the most simple solution, because I don't need any extra buffer, and I can assign the value immediately when I have the value.
I think I can postpone an assignment to svariableShutdownReceiver with a few more lines to get the behaviour that you expect.