Re: BUG #15977: Inconsistent behavior in chained transactions

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.