Re: Vote on SET in aborted transaction

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема Re: Vote on SET in aborted transaction
Дата
Msg-id 3CC76090.E1E8E25E@tpf.co.jp
обсуждение исходный текст
Ответ на Re: Vote on SET in aborted transaction  (Jan Wieck <janwieck@yahoo.com>)
Ответы Re: Vote on SET in aborted transaction  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Michael Loftis wrote:
> 
> Hiroshi Inoue wrote:
> 
> >What's wrong with it ? The insert command after *rollback*
> >would fail. It seems the right thing to me. Otherwise
> >the insert command would try to append the data of the
> >table t1 to itself. The insert command is for copying
> >schema1.t1 to foo.t1 in case the previous create schema
> >command suceeded.
> >
> Exactly, in this example shows exactly why SETs should be part of the
> transaction and roll back. Heck the insert may not even fail after all
> anyway and insert into the wrong schema. If the insert depends on the
> schema create succeeding it should be in the same transaction. (IE it
> would get rolled back or not happen at all)

Where's the restriction that all objects in a schema
must be created in an transaction ? Each user has his
reason and would need various kind of command call sequence.
What I've mainly insisted is what to do with errors is
users' responsibilty but I've never seen the agreement
for it. So my current understanding is you all
are thinking what to do with errors is system's
responsibilty. Then no matter how users call commands
the dbms must behave appropriately, mustn't it ?

regards, 
Hiroshi Inouehttp://w2422.nsk.ne.jp/~inoue/


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Vote totals for SET in aborted transaction
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Sequential Scan Read-Ahead