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.


Reply via email to