On 29 January 2018 at 14:59, Robert Zenz <robert.zenz@sibvisions.com> wrote:
> On 29.01.2018 14:36, David G. Johnston wrote:
...
> From my point of view, no, it shouldn't be changed. It has always been this way
> and I find nothing wrong with the approach, it is only something that you need
> to be aware of, that's all.
>
>> It may be worth updating the docs here...
>
> I'd vote for that. I would have expected to see this mentioned in the
> documentation a little bit more prominent than just a single sentence at the end
> of the transaction tutorial. A short section about how the transaction behaves
> in an error cases (and what to do) would be nice.
IMHO, the burden of explaining that is with those RDBMSes that don't
behave properly:
If you start a transaction and something goes wrong in the process,
the logical behaviour is to fail - the user will want to rollback to a
sane state, doing any more work is rather pointless because of that.
Allowing a commit at the end is dubious at best.
That does not exclude PG from documenting this behaviour, but I'd have
a look at the docs for those other vendors whether they perhaps
documented their irregular transactional behaviour ;)
You didn't mention which RDBMSes behave like what you expected
(probably from experience), but I seem to recall Oracle does odd stuff
like that, as well as issuing a commit to all open transactions when
any DDL happens or treating NULLs and empty literals as the same
thing. Just to say that the "big names" aren't without flaws - they're
kind of hard to fix when users probably depend on their behaviour
though.
Alban Hertroys
--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.
