Peter Eisentraut wrote:
> Michael Loftis writes:
>
> > I was under the impression that for a transaction either all commands
> > succeed or all commands fail, atleast according to everything I've ever
> > read.
>
> That's an urban legend.
>
> A transaction guarantees (among other things) that all modifications to
> the database with the transaction are done atomicly (either all or done or
> none). This does not extend to the commands that supposedly initiate such
> modifications.
>
> Take out a database other than PostgreSQL and do
>
> BEGIN; -- or whatever they use; might be implicit
> INSERT INTO existing_table ('legal value');
> barf;
> COMMIT;
>
> The INSERT will most likely succeed. The reason is that "barf" does not
> modify or access the data in the database, so it does not affect the
> transactional integrity of the database.
Ewe, we do fail that test.
> We are trying to make the same argument for SET. SET does not modify the
> database, so it doesn't have to fall under transaction control.
OK, we have three possibilities:
o All SETs are honored in an aborted transaction
o No SETs are honored in an aborted transaction
o Some SETs are honored in an aborted transaction (current)
I think the problem is our current behavior. I don't think anyone can
say our it is correct (only honor SET before the transaction reaches
abort state). Whether we want the first or second is the issue, I think.
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
