Hello,
>> I do think the fact that COMMIT in multi-statement implicit transaction
>> has some usecase, is an argument for just implementing it properly...
>
> Like Peter, I would also keep an ERROR for now, as we could always
> relax that later on.
I can agree with both warning and error, but for me the choice should be
consistent with the current behavior of COMMIT and ROLLBACK in the same
context.
pg> CREATE OR REPLACE PROCEDURE warn(msg TEXT) LANGUAGE plpgsql AS
$$ BEGIN RAISE WARNING 'warning: %', msg ; END ; $$;
Then an out-of-transaction multi-statement commit:
pg> CALL warn('1') \; COMMIT \; CALL warn('2') ;
WARNING: warning: 1
WARNING: there is no transaction in progress
WARNING: warning: 2
CALL
But v4 creates an non uniform behavior that I find surprising and
unwelcome:
pg> CALL warn('1') \; COMMIT AND CHAIN \; CALL warn('2') ;
WARNING: warning: 1
ERROR: COMMIT AND CHAIN can only be used in transaction blocks
Why "commit" & "commit and chain" should behave differently in the same
context? For me they can error or warn, but consistency implies that they
should do the exact same thing.
From a user perspective, I really want to know if a commit did not do what
I thought, and I'm certainly NOT expecting the stuff I sent to go on as if
nothing happened. Basically I agree with everybody that raising an error
is the right behavior in this case, which suggest that out-of-transaction
commit and rollback should error.
So my opinion is that commit & rollback issued out-of-transaction should
also generate an error.
If it is too much a change and potential regression, then I think that the
"and chain" variants should be consistent and just raise warnings.
--
Fabien.