Re: [PATCHES] Continue transactions after errors in psql

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [PATCHES] Continue transactions after errors in psql
Дата
Msg-id 200504251728.j3PHSk720817@candle.pha.pa.us
обсуждение исходный текст
Ответы Re: [PATCHES] Continue transactions after errors in psql  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: [PATCHES] Continue transactions after errors in psql  (Mark Kirkwood <markir@paradise.net.nz>)
Re: [PATCHES] Continue transactions after errors in psql  ("Greg Sabino Mullane" <greg@turnstep.com>)
Список pgsql-hackers
Greg Sabino Mullane wrote:
>  > The SQL-Standard itself says that errors inside transactions should only
> > rollback the last statement, if possible. So why is that not implemented in
> > PostgreSQL? What I read from past discussions here, is because it's just
> > unsave and will lead to data-garbage if you aren't very careful.
>   
> That's a good point: if that is indeed what the standard says, we should
> probably see about following it. Rolling back to the last savepoint seems
> a reasonable behavior to me.

OK, so we need to make a decision.  Right now I have Greg's patch that
is enabled by "\set ON_ERROR_ROLLBACK on":test=> \set ON_ERROR_ROLLBACK ontest=> BEGIN;BEGINtest=> lkjasdf;ERROR:
syntaxerror at or near "lkjasdf" at character 1LINE 1: lkjasdf;        ^test=> SELECT 1; ?column?----------        1(1
row)test=>COMMIT;COMMIT
 

The question is what to make the default:
disable it by default for all sessions (current patch)enable it by default only for interactive sessions, like
AUTOCOMMITenableit by default for all sessions (breaks too many apps)add a third mode called 'ttyonly' and figure out a
default

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


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

Предыдущее
От: "Dave Held"
Дата:
Сообщение: Re: [PERFORM] Bad n_distinct estimation; hacks suggested?
Следующее
От: Brent Verner
Дата:
Сообщение: [proposal] protocol extension to support loadable stream filters