Re: Now PostgreSQL recovers from errors within trns
От | Don Baccus |
---|---|
Тема | Re: Now PostgreSQL recovers from errors within trns |
Дата | |
Msg-id | 3.0.1.32.20000731100512.013b0140@mail.pacifier.com обсуждение исходный текст |
Ответ на | Re: Now PostgreSQL recovers from errors within trns (hstenger@adinet.com.uy) |
Список | pgsql-hackers |
At 02:10 PM 7/31/00 -0300, hstenger@adinet.com.uy wrote: >Tom Lane wrote: >> >> hstenger@adinet.com.uy writes: >> > My goal is to make the backend accept erroneous commands, not falling >> > in *ABORT STATE*, but rolling back automatically, & continue accepting >> > commands. >> >> The way you're doing it, you might as well just not use transaction >> blocks at all. I don't think wiping out the effects of all preceding >> commands within the transaction counts as "recovering from an error". > >Ok, maybe I exagerated, but kind of solves my problem. GeneXus, my CASE tool, >will send begin/commit pairs, so I must 'recover' automatically. I aimed >DB2-like behaviour, which I was told, aborts on errors within transactions, but >remains in a runnable state. Don't you consider it valueable whatsoever? Well, Postgresql's behavior isn't SQL92 compliant, but neither is the behavior you want. I far prefer the current non-standard behavior. Eventually, of course, PG should conform to SQL92. GeneXus should be catching the error and issuing a rollback if that's the behavior it expects. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: