Re: Problem with aborting entire transactions on error
От | Zbigniew |
---|---|
Тема | Re: Problem with aborting entire transactions on error |
Дата | |
Msg-id | CALT7RM8jOPu7f=zFBHC7a=U0xJwcJvzVt9ZGFS4d46B8377Pig@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Problem with aborting entire transactions on error (Chris Angelico <rosuav@gmail.com>) |
Ответы |
Re: Problem with aborting entire transactions on error
|
Список | pgsql-general |
2012/12/10, Chris Angelico <rosuav@gmail.com>: > Are you a programmer? Are you aware how much complexity each option > adds? Every single combination must be tested and debugged. In this > instance, that means testing every part of Postgres before and after > several types of failure, to make sure everything works correctly in > both cases. That is not cheap. And then there's the user-facing > complexity (documenting the option, explaining when it's useful, etc), > and now everyone has to decide whether or not to use it. Also not > cheap. It's not that bad, that really "each option adds much complexity", and has to be tested then in every single combination of parameters/settings etc. Just one example: introducing an option "save preferences" doesn't require this. > I'm not a PG dev, but I've fought the battle against complexity in > enough other situations that I know that it's much more usual to > underestimate than overestimate the cost. There are always TWO sides (at least two): creators/designers - and the users. Considering how much complexity some kind of modification adds to your - programmer's - code, and how it'll make your life more difficult, at the same time try to consider, how much relief could it mean to many of the users of your software. -- regards, Zbigniew
В списке pgsql-general по дате отправления: