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 по дате отправления:

Предыдущее
От: Chris Angelico
Дата:
Сообщение: Re: large database
Следующее
От: Abel Abraham Camarillo Ojeda
Дата:
Сообщение: Re: Problem with aborting entire transactions on error