On Sun, Feb 23, 2020 at 7:59 PM Dave Cramer <davecramer@postgres.rocks> wrote:
>
> I think the fact that this is a violation of the SQL SPEC lends considerable credence to the argument for changing
thebehaviour.
> Since this can lead to losing a transaction I think there is even more reason to look at changing the behaviour.
The assumption that COMMIT terminates the transaction is going to be
deeply embedded into many applications. It's just too convenient not
to rely on. For example, I maintain a bash based deployment framework
that assembles large SQL files from bit and pieces and tacks a COMMIT
at the end. It's not *that* much work to test for failure and add a
rollback but it's the kind of surprise our users hate during the
upgrade process.
Over the years we've tightened the behavior of postgres to be inline
with the spec (example: Tom cleaned up the row-wise comparison
behavior in 8.2) but in other cases we had to punt (IS NULL/coalesce
disagreement over composites for example), identifier case sensitivity
etc. The point is, changing this stuff can be really painful and we
have to evaluate the benefits vs the risks.
My biggest sense of alarm with the proposed change is that it could
leave applications in a state where the transaction is hanging there
it could previously assume it had resolved; this could be catastrophic
in impact in certain real world scenarios. Tom is right, a GUC is the
equivalent of "sweeping the problem under the wrong" (if you want
examples of the long term consequences of that vision read through
this: https://dev.mysql.com/doc/refman/8.0/en/timestamp-initialization.html).
The value proposition of the change is however a little light
relative to the risks IMO.
I do think we need to have good page summarizing non-spec behaviors in
the documentation however.
merlin
