Re: autocommit vs TRUNCATE et al

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: autocommit vs TRUNCATE et al
Date: 2002-10-19 01:39:01
Message-ID: 200210190139.g9J1d1J08870@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway wrote:
> Bruce Momjian wrote:
> >>most useful approach. The analogy to SET hadn't occurred to me.
> >
> >
> > Yea, the SET behavior appeared pretty queer to me, but now that I have
> > used it, I am getting used to it.
> >
>
> So does that mean:
>
> set autocommit to off;
> begin;
> insert into foo values('a');
> insert into bar values('b');
> truncate table foobar;
>
> will automatically commit the two inserts?

No, the entire transaction will aborted because TRUNCATE has to be at
the start of a multi-statement transaction. This will also fail:

> set autocommit to off;
> begin;
> truncate table foobar;
> insert into foo values('a');
> insert into bar values('b');

but this will work:

> set autocommit to off;
> truncate table foobar;
> insert into foo values('a');
> insert into bar values('b');

In the last case, the TRUNCATE will happen, and the INSERTs will be in
their own multi-statement transaction. A SET in place of TRUNCATE will
behave the same way.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-10-19 01:45:50 Re: autocommit vs TRUNCATE et al
Previous Message Joe Conway 2002-10-19 01:34:16 Re: autocommit vs TRUNCATE et al