Re: AW: AW: [HACKERS] TRANSACTIONS

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: AW: AW: [HACKERS] TRANSACTIONS
Дата
Msg-id 22076.951410058@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: AW: AW: [HACKERS] TRANSACTIONS  (Don Baccus <dhogaza@pacifier.com>)
Ответы Re: AW: AW: [HACKERS] TRANSACTIONS  (Don Baccus <dhogaza@pacifier.com>)
Список pgsql-hackers
Don Baccus <dhogaza@pacifier.com> writes:
> It is up to the application or user to rollback the entire transaction
> if that's the behavior that's desired.

> Of course the whole concept of an explicit "begin" is non-standard,
> too.  In SQL you're always in a transaction, commit and rollback
> terminate transactions and start a new one.

True, although SQL doesn't mandate exactly how that is accomplished.
We have some client interfaces that provide that behavior,
and that's a compliant way of doing it AFAICS.

We ought to consider ways of providing the same behavior in psql,
but it's not gonna happen for 7.0 --- too big a change for beta.

> I suspect that most applications don't notice the difference.   Most
> will catch errors and roll back the current transaction, because that's
> the logical thing to do in most cases.

You are assuming that the app has the intelligence to do so.  A psql
script, for example, lacks that intelligence.

I do agree that this is an area where we need to do some work, but
it's not going to be a simple or small change.  We will need nested-
transaction support in the backend, and some very careful rethinking
of the client interfaces to try to avoid breaking existing apps.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0
Следующее
От: "Post Message"
Дата:
Сообщение: Solid time