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.