On 29 January 2018 at 14:59, Robert Zenz <robert.zenz@xxxxxxxxxxxxxx> 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.
