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
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 |