Re: [GENERAL] How to stop implicit rollback on certain errors?
От | Ross J. Reedstrom |
---|---|
Тема | Re: [GENERAL] How to stop implicit rollback on certain errors? |
Дата | |
Msg-id | 19991209102418.A6311@rice.edu обсуждение исходный текст |
Ответ на | Re: [GENERAL] How to stop implicit rollback on certain errors? (Lincoln Yeoh <lylyeoh@mecomb.com>) |
Список | pgsql-general |
Hmm, sounds like a vote for nested transactions. The JDBC driver developer (Peter Mount) was musing that nested transaction would make large object support easier for him, as well. As to the other example of Oracle not forcing a rollback, I have a feeling that this may be specific to syntax errors in an interactive session. Implementing this sort of behavior has been discussed recently on the hackers list, in the context of making it easier to work interactively inside a transaction. I would be surprised if Oracle allows non-syntax errors inside a transaction to be ignored, or ignores anything in a non-interactive session. How about testing an example like links, where you provide data in a format the backend can't handle, (an out of range int or date or something) and see how Oracle handles that. Who's right? Well, as Peter Eisentraut said, what Postgres implements is the _definition_ of a transaction: all together, or nothing at all. This isn't just an arbitrary rule: the validity of the relational calculus depends on transactional semantics. Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005 On Thu, Dec 09, 1999 at 09:23:35AM +0800, Lincoln Yeoh wrote: > At 01:18 AM 09-12-1999 +0100, Peter Eisentraut wrote: > >Seriously, why do you use a transaction, when you don't want any errors > >caught? Transactions are defined as everything succeeds or nothing goes. > >If you want update to succeed anyhow, put it in it's own transaction > >(i.e., commit before it). > > I want errors caught, most errors abort everything but some errors I want > to try a different update instead, if that doesn't work then only rollback > everything. > > >> I guess that's expected, and I should insert big years using another less > >> ambiguous format. What is the recommended format? > > > >The safest way would be to set a date format with SET DATESTYLE TO and use > >that, possibly assisted by library formatting routines. > > OK. > > Link. > > > ************ >
В списке pgsql-general по дате отправления: