autocommit vs TRUNCATE et al

Поиск
Список
Период
Сортировка
От Tom Lane
Тема autocommit vs TRUNCATE et al
Дата
Msg-id 13776.1034989477@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: autocommit vs TRUNCATE et al  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: autocommit vs TRUNCATE et al  (Gavin Sherry <swm@linuxworld.com.au>)
Список pgsql-hackers
There are a number of statements, such as TRUNCATE TABLE, that refuse to
run in a transaction block because they perform actions that can't be
rolled back later.

These statements currently do not look at autocommit, which means that
if autocommit is off, their tests will succeed ... but then a
transaction block is started anyway, defeating the point of the test.

We could fix these statements to fail if autocommit is off, which means
that you could not use them at all except by setting autocommit on.
Ugh.

Or we could fix them to force an autocommit.  Which would mean that
these "dangerous" statements would become even more dangerous, since
that's exactly the behavior a person using autocommit-off would not
expect.  Also ugh.

Anyone see a way out of this catch-22?  If not, which is the least
bad alternative?
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: compile error in CVS HEAD
Следующее
От: Joe Conway
Дата:
Сообщение: Re: autocommit vs TRUNCATE et al