Mike Rogers wrote:
>
> What that does is very simple: it rolls back the one that is keeping track
> of it's transactions. Think of the overhead if someone doesn't have
> transactional statements. The idea is, in PGSQL, all inserts and updates
> are essentially logged so that they can be rolled back. Here is the MySQL
> concept:
> Have a log table that logs all transactions (lets say, failed or not)
> 1. begin transaction
> 2. insert into non-transactional table 'user did this,
> status - unprocessed'
> 3. insert into payment table
> 4. insert into product table
> 5. update to processed
> 6. insert into shipping
> 7. update to 'pending shipping'
> Perfectly common transaction that happens. Now! What if you want the
> entry inserted and dealt with as a status and what happens, but you don't
> want all the evidence of that to disappear when you hit rollback.
> It means you can have some things roll back and others don't. In PGSQL,
> that would have to be begin/rollback for only transactional entries.
Or you would run two parallel transactions (currently you need two
connections
for this) - one for logging and one for work.
I agree that having non_transactional (i.e. logging) tables may be
sometimes
desirable. I've been told that some of Oracles debugging/logging
facilities
are almost useless due-to the fact that they disappear at rollback.
------------------
Hannu