> Missed them somehow. But I don't think they're quite sufficient. I think
> at least we also need tests that test things like multi-statement
> exec_simple-query() *with* explicit transactions and chaining.
Added a few more tests for that.
> Now, I'd prefer error in all cases, no doubt about that, which might be
> considered a regression. A way around that could be to have a GUC decide
> between a strict behavior (error) and the old behavior (warning).
I think it's more better to have a GUC to disable implicit transaction 'block' feature, because that's probably the root of all issues.
> I made another patch for that.
> I don't have much confidence with my English spelling so further
> improvements may be needed.
>
>> 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.
> We don't have an exact answer for implicit transaction chaining behavior
> yet.
> So I think it's better to disable this feature until someone discovers the
> use cases for this.
> Permitting AND CHAIN without a detailed specification might cause troubles
> in future.
I think that it would be too bad to remove this feature for a small
implementation-dependent corner case.
Documentation says that COMMIT/ROLLBACK [AND CHAIN] apply to the "current
transaction", and "BEGIN initiates a transaction block".
If there is no BEGIN, there is no "current transaction", so basically the
behavior is unspecified, whether AND CHAIN or not, and we are free
somehow.
In such case, I'm simply arguing for consistency: whatever the behavior,
the chain and no chain variants should behave the same.
Now, I'd prefer error in all cases, no doubt about that, which might be
considered a regression. A way around that could be to have a GUC decide
between a strict behavior (error) and the old behavior (warning).
--
Fabien.
